I am very happy that objects have finally been released. I’ve followed all the discussions about OO with occasional insterest and sometimes horror. The endless discussions of possible extensions has confused me mightily. The concurrent modification of the documentation by Vulcan, though well intentioned, is in my opinion a disaster. Let me give a couple of examples. I would like to recode my small personal library using objects. Using objects to create a local namespace seems like a good idea but requires module references. With all the talk about them I have lost track of whether the latest build has them or not. I can’t trust the documentation to tell me. Apparently not supported yet. I put together a module that would take a 2D path in 3D space and do a linear extrude along the normal of the 2D polygon. I have always been a bit confused about when a path becomes 2D geometry and can no longer be accessed as data. For example I would like to be able to get circle() to produce a path. That didn’t seem to work. I went to the wiki to try and understand. The muddling of terms by Vulcan made the exercise impossible. I So my linear_extrude3d module works using ideas and functions from BOSL2. I had to just muddle thru. The discussions on object took a frustrating turn when it was suggested that object implies inheritance so OpenSCAD should support full inheritance. Since when has any thought that experience with any previous language should create expectations of OpenSCAD? I have no idea how many languages I have written code in by now, certainly dozens, a few I even created myself. OpenSCAD has rules that I can’t remember a single other language with an equivalent. It’s fine though! It works! Adding multiple inheritance? Good grief no. Overloading? It would be wasteful syntactic sugar. The peculiarities of OpenSCAD are bad enough without adding stuff like this. I fully support the maintainers practice of keeping enhancements as simple as possible. The discussion of "center" has been refreshingly down to earth. I personally don’t care because I actually code in OpenSCAD-BOSL2. I wish the namespaces for libraries would get solved. Like objects, it seems like it’s been juts over the horizon for years. That’s 100 times more useful than overloading or inheritance. -Bob

I don't see the problem with centre because when I model it's about 50/50 if I want something centred. On Mon, 25 Aug 2025 at 22:02, Bob Carlson via Discuss < discuss@lists.openscad.org> wrote: > I am very happy that objects have finally been released. I’ve followed all > the discussions about OO with occasional insterest and sometimes horror. > > The endless discussions of possible extensions has confused me mightily. > The concurrent modification of the documentation by Vulcan, though well > intentioned, is in my opinion a disaster. > > Let me give a couple of examples. I would like to recode my small personal > library using objects. Using objects to create a local namespace seems like > a good idea but requires module references. With all the talk about them I > have lost track of whether the latest build has them or not. I can’t trust > the documentation to tell me. Apparently not supported yet. > > I put together a module that would take a 2D path in 3D space and do a > linear extrude along the normal of the 2D polygon. I have always been a bit > confused about when a path becomes 2D geometry and can no longer be > accessed as data. For example I would like to be able to get circle() to > produce a path. That didn’t seem to work. I went to the wiki to try and > understand. The muddling of terms by Vulcan made the exercise impossible. I > So my linear_extrude3d module works using ideas and functions from BOSL2. I > had to just muddle thru. > > The discussions on object took a frustrating turn when it was suggested > that object implies inheritance so OpenSCAD should support full > inheritance. Since when has any thought that experience with any previous > language should create expectations of OpenSCAD? I have no idea how many > languages I have written code in by now, certainly dozens, a few I even > created myself. OpenSCAD has rules that I can’t remember a single other > language with an equivalent. It’s fine though! It works! > > Adding multiple inheritance? Good grief no. Overloading? It would be > wasteful syntactic sugar. The peculiarities of OpenSCAD are bad enough > without adding stuff like this. I fully support the maintainers practice of > keeping enhancements as simple as possible. The discussion of "center" has > been refreshingly down to earth. I personally don’t care because I actually > code in OpenSCAD-BOSL2. > > I wish the namespaces for libraries would get solved. Like objects, it > seems like it’s been juts over the horizon for years. That’s 100 times more > useful than overloading or inheritance. > > -Bob > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org

module basic( shape) {
    if ( shape.type == Type.MOVE ) {
        translate( shape.size ) 
    basic( shape.child );
    } else if ( shape.type == Type.CUBE ) {
        cube(shape.size, center=true);
    } else if ( shape.type == Type.CYL ) {
        translate([0,0,-shape.size.z/2]) 
        scale( shape.size ) cylinder(d=1,h=1);
    }
}

difference() {
    basic( shape ); // outer
    if ( shape.wall ) {
        basic( shape.inner() );				
    }
}

Peter

You can find the working proposal for the $this here: https://github.com/openscad/openscad/pull/6022 If you can't build it yourself and you're on a Mac, I'd be happy to send you the App to play with. It actually works like a charm! This PR has unfortunately NO module references. I started working on module references but lost appetite after the train wreck here around objects. A workaround to the limitation that lack of reference gives, is to only have functions in the object and then have one global module `mylib_render(object)` in the global namespace that figures out what to do based in info in the object. Not perfect, but the enemy of good is better. The following is the kind of code I was thinking of for a library. (This is not a proposal or anything real, it is just a working sketch I made an hour.) Type = object( MOVE="move", CUBE="cube", CYL="cyl" ); Move = object( type=Type.MOVE, size=[0,0,0]); Shape = object( size = [1,1,1], wall = 0, inner = function() let ( z = closed ? 2*wall : wall, shape = object( $this, size = size-[2*wall,2*wall,z] ), ) Mylib.move( vector=[0,0,z], shape ), // inner ); Cube = object( Shape, type = Type.CUBE ); Cyl = object( Shape, type = Type.CYL, ); Mylib = object( cube = function( size, wall=0, closed=false ) object( Cube, size = size, wall = wall, closed = closed, ), cyl = function( size, wall=0, closed=false ) object( Cyl, size = size, wall = wall, closed = closed, ), move = function( vector, shape ) object( Move, size = vector, child = shape ), ); module mylib( shape ) { module basic( shape) { if ( shape.type == Type.MOVE ) { translate( shape.size ) basic( shape.child ); } else if ( shape.type == Type.CUBE ) { cube(shape.size, center=true); } else if ( shape.type == Type.CYL ) { translate([0,0,-shape.size.z/2]) scale( shape.size ) cylinder(d=1,h=1); } } difference() { basic( shape ); // outer if ( shape.wall ) { basic( shape.inner() ); } } } // examples $fn=100; translate([-5,0,0]) { s = Mylib.cube( size=[5,10,5], wall=1 ); mylib(s); } translate([5,0,0]) { s = Mylib.cyl( size=[5,10,5], wall=0.5 ); mylib(s); } This works in my PR and gives:  I find it a real pity that $this got derailed because I really would like to get your kind of experiences to see what details can be improved. The library use case is for me very important. (To my eternal regret I am a yack shaver. (I could've been rich!) I'd liked to contribute to BOSL, but after 45 years of writing OO (really!) my hands are incapable of writing array code ... so I needed objects in OpenSCAD so I can shave my yacks in BOSL ... Sigh.) Peter > On 25 Aug 2025, at 23:02, Bob Carlson via Discuss <discuss@lists.openscad.org> wrote: > > I am very happy that objects have finally been released. I’ve followed all the discussions about OO with occasional insterest and sometimes horror. > > The endless discussions of possible extensions has confused me mightily. The concurrent modification of the documentation by Vulcan, though well intentioned, is in my opinion a disaster. > > Let me give a couple of examples. I would like to recode my small personal library using objects. Using objects to create a local namespace seems like a good idea but requires module references. With all the talk about them I have lost track of whether the latest build has them or not. I can’t trust the documentation to tell me. Apparently not supported yet. > > I put together a module that would take a 2D path in 3D space and do a linear extrude along the normal of the 2D polygon. I have always been a bit confused about when a path becomes 2D geometry and can no longer be accessed as data. For example I would like to be able to get circle() to produce a path. That didn’t seem to work. I went to the wiki to try and understand. The muddling of terms by Vulcan made the exercise impossible. I So my linear_extrude3d module works using ideas and functions from BOSL2. I had to just muddle thru. > > The discussions on object took a frustrating turn when it was suggested that object implies inheritance so OpenSCAD should support full inheritance. Since when has any thought that experience with any previous language should create expectations of OpenSCAD? I have no idea how many languages I have written code in by now, certainly dozens, a few I even created myself. OpenSCAD has rules that I can’t remember a single other language with an equivalent. It’s fine though! It works! > > Adding multiple inheritance? Good grief no. Overloading? It would be wasteful syntactic sugar. The peculiarities of OpenSCAD are bad enough without adding stuff like this. I fully support the maintainers practice of keeping enhancements as simple as possible. The discussion of "center" has been refreshingly down to earth. I personally don’t care because I actually code in OpenSCAD-BOSL2. > > I wish the namespaces for libraries would get solved. Like objects, it seems like it’s been juts over the horizon for years. That’s 100 times more useful than overloading or inheritance. > > -Bob > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org

 module basic( shape) {
     if ( shape.type == Type.MOVE ) {
         translate( shape.size ) 
    basic( shape.child );
     } else if ( shape.type == Type.CUBE ) {
         cube(shape.size, center=true);
     } else if ( shape.type == Type.CYL ) {
         translate([0,0,-shape.size.z/2]) 
         scale( shape.size ) cylinder(d=1,h=1);
     }
 }

 difference() {
     basic( shape ); // outer
     if ( shape.wall ) {
         basic( shape.inner() );				
     }
 }

Peter

I gave it a few minutes and I cannot understand what’s going on. If it’s not intuitive and doesn’t follow easily from existing OpenSCAD, I don’t think it helps. It’s just an academic exercise. (And I share your age AND preference for OO.) -Bob > On Aug 27, 2025, at 06:45, Peter Kriens <peter.kriens@aqute.biz> wrote: > > You can find the working proposal for the $this here: https://github.com/openscad/openscad/pull/6022 > > If you can't build it yourself and you're on a Mac, I'd be happy to send you the App to play with. It actually works like a charm! > > This PR has unfortunately NO module references. I started working on module references but lost appetite after the train wreck here around objects. > > A workaround to the limitation that lack of reference gives, is to only have functions in the object and then have one global module `mylib_render(object)` in the global namespace that figures out what to do based in info in the object. Not perfect, but the enemy of good is better. > > The following is the kind of code I was thinking of for a library. (This is not a proposal or anything real, it is just a working sketch I made an hour.) > > Type = object( MOVE="move", CUBE="cube", CYL="cyl" ); > Move = object( type=Type.MOVE, size=[0,0,0]); > Shape = object( > size = [1,1,1], > wall = 0, > inner = function() > let ( > z = closed ? 2*wall : wall, > shape = object( > $this, > size = size-[2*wall,2*wall,z] > ), > ) > Mylib.move( vector=[0,0,z], shape ), // inner > ); > Cube = object( > Shape, > type = Type.CUBE > ); > Cyl = object( > Shape, > type = Type.CYL, > ); > > Mylib = object( > cube = function( size, wall=0, closed=false ) object( > Cube, > size = size, > wall = wall, > closed = closed, > ), > cyl = function( size, wall=0, closed=false ) object( > Cyl, > size = size, > wall = wall, > closed = closed, > ), > move = function( vector, shape ) object( > Move, > size = vector, > child = shape ), > ); > > module mylib( shape ) { > > module basic( shape) { > if ( shape.type == Type.MOVE ) { > translate( shape.size ) > basic( shape.child ); > } else if ( shape.type == Type.CUBE ) { > cube(shape.size, center=true); > } else if ( shape.type == Type.CYL ) { > translate([0,0,-shape.size.z/2]) > scale( shape.size ) cylinder(d=1,h=1); > } > } > > difference() { > basic( shape ); // outer > if ( shape.wall ) { > basic( shape.inner() ); > } > } > } > > > // examples > $fn=100; > translate([-5,0,0]) { > s = Mylib.cube( size=[5,10,5], wall=1 ); > mylib(s); > } > translate([5,0,0]) { > s = Mylib.cyl( size=[5,10,5], wall=0.5 ); > mylib(s); > } > > This works in my PR and gives: > <PastedGraphic-3.png> > > I find it a real pity that $this got derailed because I really would like to get your kind of experiences to see what details can be improved. The library use case is for me very important. (To my eternal regret I am a yack shaver. (I could've been rich!) I'd liked to contribute to BOSL, but after 45 years of writing OO (really!) my hands are incapable of writing array code ... so I needed objects in OpenSCAD so I can shave my yacks in BOSL ... Sigh.) > > Peter > >> On 25 Aug 2025, at 23:02, Bob Carlson via Discuss <discuss@lists.openscad.org> wrote: >> >> I am very happy that objects have finally been released. I’ve followed all the discussions about OO with occasional insterest and sometimes horror. >> >> The endless discussions of possible extensions has confused me mightily. The concurrent modification of the documentation by Vulcan, though well intentioned, is in my opinion a disaster. >> >> Let me give a couple of examples. I would like to recode my small personal library using objects. Using objects to create a local namespace seems like a good idea but requires module references. With all the talk about them I have lost track of whether the latest build has them or not. I can’t trust the documentation to tell me. Apparently not supported yet. >> >> I put together a module that would take a 2D path in 3D space and do a linear extrude along the normal of the 2D polygon. I have always been a bit confused about when a path becomes 2D geometry and can no longer be accessed as data. For example I would like to be able to get circle() to produce a path. That didn’t seem to work. I went to the wiki to try and understand. The muddling of terms by Vulcan made the exercise impossible. I So my linear_extrude3d module works using ideas and functions from BOSL2. I had to just muddle thru. >> >> The discussions on object took a frustrating turn when it was suggested that object implies inheritance so OpenSCAD should support full inheritance. Since when has any thought that experience with any previous language should create expectations of OpenSCAD? I have no idea how many languages I have written code in by now, certainly dozens, a few I even created myself. OpenSCAD has rules that I can’t remember a single other language with an equivalent. It’s fine though! It works! >> >> Adding multiple inheritance? Good grief no. Overloading? It would be wasteful syntactic sugar. The peculiarities of OpenSCAD are bad enough without adding stuff like this. I fully support the maintainers practice of keeping enhancements as simple as possible. The discussion of "center" has been refreshingly down to earth. I personally don’t care because I actually code in OpenSCAD-BOSL2. >> >> I wish the namespaces for libraries would get solved. Like objects, it seems like it’s been juts over the horizon for years. That’s 100 times more useful than overloading or inheritance. >> >> -Bob >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >

*I gave it a few minutes and I cannot understand what’s going on. * Me, too! It seems like a LOT of code that could be implemented easier with plain ol' OpenSCAD modules.

On 8/28/2025 3:39 AM, Leonard Martin Struttmann via Discuss wrote: > Me, too! It seems like a LOT of code that could be implemented easier > with plain ol' OpenSCAD modules. Without talking about any particular replacement style... the problem with plain ol' OpenSCAD modules is naming. BOSL2, for instance, undoubtedly has numerous internal functions and modules.  They exist to help it do its work; they are not for your use and so are not documented. What happens if you happen to define a module with the same name as one of BOSL2's internal modules?  Nothing good, I'm sure. Heck, BOSL2 has a *lot* of documented modules; do you keep a full list in your head as names to avoid? And if you *do* avoid all of BOSL2's names... will tomorrow's version add a new name that conflicts with a name in your project? And if you want to use BOSL2 in conjunction with some other library, do they have names that conflict? The goal of this particular sub-effort (or you might see reference to a "namespace" effort with similar goals) is to allow a library to isolate its names, so that you only get the library's module when you specifically ask for it.

And if you don't use or write libraries, or the libraries that you use or write haven't chosen to adopt whatever name management scheme we come up with, then the effect on you is almost exactly zero. (There may be a few new names that you must avoid.)