Re: New feature in 2025.07.11: the object() function
Apparently yes, sorry for that . Thanks for clarificaton.😜
Cory Cross openscad@corycross.org schrieb am Fr., 15. Aug. 2025, 19:47:
On 8/15/25 10:44 AM, Guenther Sohler via Discuss wrote:
Nope i disagree Here.
PythonSCAD is Not reinventing the wheel, its a Mix of leveraging existing
Technology, Bridging 2 worlds(Python and Scad are very interlinked) and
Quite some offering Features which openscad Refuse to have for Ages
I think you misread Jordan; he's saying adding too much OO stuff to the
OpenSCAD language is reinventing the wheel, and suggests PythonSCAD is
the better approach. I think he agrees with what you wrote.
On 8/15/2025 7:47 PM, Cory Cross via Discuss wrote:
On 8/15/25 10:44 AM, Guenther Sohler via Discuss wrote:
Nope i disagree Here.
PythonSCAD is Not reinventing the wheel, its a Mix of leveraging
existing
Technology, Bridging 2 worlds(Python and Scad are very interlinked) and
Quite some offering Features which openscad Refuse to have for Ages
I think you misread Jordan; he's saying adding too much OO stuff to
the OpenSCAD language is reinventing the wheel, and suggests
PythonSCAD is the better approach. I think he agrees with what you wrote.
Yes.
If it wasn't for the sandboxing issue, I'd switch over to something
Python-based in a heartbeat.
Let's not further discuss PythonSCAD in this thread. That's not what
it's about; this thread is about the evolution of the OpenSCAD language,
not about replacing it with a different language. The only way that
replacing it with a different language is relevant is when and if we
decide that the rabbit hole is deep enough and say "that's as far as
we're going to go; if you want more go to another language".
On 8/15/2025 7:51 PM, Cory Cross wrote:
On 8/15/25 10:27 AM, Jordan Brown via Discuss wrote:
[Has ES/JS] added a real [super]?
Yes.
Thanks. I'll need to look at that.
You've got some goals and are trying to make /object/ work for them. I
think the goals are:
-
Replace hardcoded [1] and [CONSTANT] index into arrays by being
able to name values by identifier -
Be able to namespace functions, modules, and constants.
Yes. And eventually maybe some of the other OO things like better
modularity and information hiding and sharing implementation and
definition for common behaviors.
- Be able to assert some piece of data as conforming to some standard
(i.e. data validation in constructor, expect method X to exist, etc).
Maybe. OpenSCAD is, like JavaScript and Python, a type-unsafe
language. That's why I've been looking to those two for patterns to
follow. That limits the amount that you can assert.
I actually prefer type-safe languages. (Java isn't quite type-safe
enough for my preferences.)Â I fantasize about a language where if you
tried to add meters to grams it would be a type error. But they are
difficult for beginners, and the beginner audience is important here.
I don't think prototype inheritance is a great fit for a language with
immutable data types. I think either generic functions or class
definitions are a better fit. Just because you /can/ use
/object/+lambdas to keep many things you want doesn't mean you /should/.
Perhaps I just don't know enough OO theory.
I like JS because it has relatively simple building blocks, and yet you
can build very complex and powerful things with it. (Contrast with C++,
which adds so many syntactic and semantic constructs to C that it makes
me dizzy.)Â JS has been what I've been primarily looking to in thinking
about adding OO-ish features to OpenSCAD.
BTW, note that I think that what we're talking about is of interest to
less than one in ten OpenSCAD users, and quite possibly less than one in
a hundred. I expect that people like Adrian and Revar (authors of
BOSL2) are very interested, but I'm a pretty advanced user and I run out
of interest shortly after getting the basic data-only objects, and
almost completely once we have "this". I don't think my projects would
benefit from "super". (But, indirectly, if it helps build BOSL2++, it
helps me.)
Not that I don't have fun thinking about it... but that has nothing to
do with my use of OpenSCAD.
On 15.08.25 20:20, Jordan Brown via Discuss wrote:
And eventually maybe some of the other OO things
What for? OO is for books and GUI libraries, otherwise it's
a mostly failed paradigm...
If we really want to offer a real OO language, I'd suggest
looking at an existing language and support that in addition
to the simple and approachable scripting we have now that
works for people who are not, and likely don't want to be
programmers.
ciao,
Torsten.
I am (and want to continue being) a programmer, in fact, writing the code, coming up with ways to make efficiently reusable functions & modules, manipulating the arrays & data, and other factors, are my favorite part of OpenSCAD. The reason I chose OpenSCAD instead of a more GUI-based designer was because I LIKE programming. Take away the code aspect, and I might end up ditching 3D printing as what is now one of the biggest parts of my life and hobbies. But back to the topic. Full-fledged languages are intended to be used for, well, everything, and that is why they don't have built-in geometry functions for things like 3D, they inherit classes & libraries. So developers somewhere down the line had to write them, but they still used the same core language. OpenSCAD is a language designed & optimized for one, and only one, purpose: 3D Printing. But I will also note that OpenSCAD isn't really a "programming" language at all, it is a "scripting" language. I am as happy as anybody about object() being implemented, but even a techie knows that things can go overboard. Are there features I would like to see that do not yet exist? Of course (maybe function/module overloading), but taking away the simplicity of OpenSCAD make it lose it's appeal. Right now, I would simply add the basic object(), it will take us a while to update all our existing code, so I think it is best to let us get started on that before obsessing over other stuff.
Nathan Sokalski
njsokalski@hotmail.commailto:njsokalski@hotmail.com
From: Torsten Paul via Discuss discuss@lists.openscad.org
Sent: Friday, August 15, 2025 3:13 PM
To: discuss@lists.openscad.org discuss@lists.openscad.org
Cc: Torsten Paul Torsten.Paul@gmx.de
Subject: [OpenSCAD] Re: New feature in 2025.07.11: the object() function
On 15.08.25 20:20, Jordan Brown via Discuss wrote:
And eventually maybe some of the other OO things
What for? OO is for books and GUI libraries, otherwise it's
a mostly failed paradigm...
If we really want to offer a real OO language, I'd suggest
looking at an existing language and support that in addition
to the simple and approachable scripting we have now that
works for people who are not, and likely don't want to be
programmers.
ciao,
Torsten.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 8/15/2025 9:51 PM, Nathan Sokalski via Discuss wrote:
but taking away the simplicity of OpenSCAD make it lose it's appeal.
Indeed, one of the tricky questions is how to structure the
documentation and other materials so that a beginner can learn to do
simple things easily, but can progress to doing very advanced things.
We already have that problem; if you're not careful the fundamentals of
cube, cylinder, sphere, translate, rotate, union, difference,
intersection can get lost in discussions of special variables, children,
magic function operators, and so on.
In my experience an extremely well defined order is paramount. Without
a defined order we could not even run our tests since it checks the
output of echo, which uses that order.
The testing issue can be addressed by sorting by key (probably in the
test) while printing the object. That puts any performance cost in the
test, rather than in production.
I'd like objects to allow non-string keys in the future.
I think you want way too much here :-)
I want it all, and I want it now!
That would be a map and that is in my mind a very different beast then
an object.
I think we have two analogs:Â JavaScript objects and either Python
objects or Python dictionaries.
One of the early commenters opined that what we were building was
more akin to dictionaries than anything else. Coming more from a JS
background, I didn't agree, and didn't even really see the
distinction he was making, and I never got a clear answer as to what
the distinction was.
JS allows numbers as keys, but does it (at least sort of) by turning
them into strings. You can set x[1] and then access it as x['1'], or
vice versa.
Python dictionaries allow numbers as keys, and they seem to retain their
number-ness.
I'm not sure, but I don't think that Python objects directly allow for
computed keys, so I find them a lot less interesting.
Our 'object' is what a struct or record is in most languages. It has
field names that are known to the code, it is a type.
No, the field names are not necessarily known to the program. That's why
you can use vector form when creating an object with object(), and why
you can access object members using o[expr] notation, to allow for keys
that are dynamically constructed.
In a map you have a mapping from one value to another, which is
fundamentally different.
How? In both of them you have a key, and it has a corresponding value.Â
Seems fundamentally the same.
 A map requires customization for the key types because for
performance you need to define a search algorithm like hashing or
ordered so you likely have several different map types. You probably
also will need counting maps, ordered maps, sorted maps, etc.
And yet I don't think that JS or Python have any of those things.Â
(Though my Python knowledge is only mediocre and my JS knowledge is old.)
On Fri, 2025-08-15 at 19:27 +0200, Jordan Brown via Discuss wrote:
 There's more than one style of OO inheritance. What we've got
here is more like the JavaScript "prototype object" style of
inheritance:Â you can take an object that you like, and make a
modified copy of it.
 The difference is you can't have super, which ECMAScript does
have.Â
I'm afraid my ES/JS experience, though pretty extensive, is for work-
legacy reasons primarily with a 2006-ish version of JS. At that point
it didn't have a super, but you could carefully build something
that more or less worked. Have they added a real one?
But yes, that's a concern. See the comment I just added to PR#6022.
A key question is just how far down the rabbit hole we want to g
Do we want to turn OpenSCAD into a full-scale OO environment? Can we
even do that without losing its appeal to beginners? There's already
an avenue for that, if you're willing to accept the security issues:Â
PythonSCAD. Language design and implementation is kind of fun, but
is reinventing the wheel, usually poorly.
I recommend OpenSCAD to beginners very often; whenever someone asks how
to model something or modify an STL. I do this because I find it easy
to understand, and because I do not get along with GUI-based CAD
Software.
Along with that I also recommend BOSL2, and point them to the Wiki. I
feel that OpenSCAD should remain OpenSCAD, and that if anything smacks
of Python or OO code, I would want to be able to continue using and
recommending it without having to struggle with those things.
I have programmed in many different languages in my career, but I am
absolutely done with learning a new one.
I have some ideas for super, but the rabbit hole keeps getting
deeper...
On 8/16/2025 2:37 AM, larry via Discuss wrote:
Along with that I also recommend BOSL2, and point them to the Wiki. I
feel that OpenSCAD should remain OpenSCAD, and that if anything smacks
of Python or OO code, I would want to be able to continue using and
recommending it without having to struggle with those things.
If what you were doing yesterday doesn't still work tomorrow, and it's
not incredibly obscure, that's a compatibility bug and we should almost
never allow it.
If a beginner trying to learn can see very much of the hypothetical OO
framework, that's a documentation failure, just as it's a failure if
they need to understand the behavior of special variables or children().
What a beginner might see is cleaner and simpler APIs to things like BOSL2.
that's a compatibility bug and we should almost never allow it.
Well I think it was you that deprecated variables that begin with a number
that broke my library, so I have to use versions before that and the change
to the semantics of $variables means I need to use the last release for
command line builds.
On Sat, 16 Aug 2025 at 06:48, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 8/16/2025 2:37 AM, larry via Discuss wrote:
Along with that I also recommend BOSL2, and point them to the Wiki. I
feel that OpenSCAD should remain OpenSCAD, and that if anything smacks
of Python or OO code, I would want to be able to continue using and
recommending it without having to struggle with those things.
If what you were doing yesterday doesn't still work tomorrow, and it's not
incredibly obscure, that's a compatibility bug and we should almost never
allow it.
If a beginner trying to learn can see very much of the hypothetical OO
framework, that's a documentation failure, just as it's a failure if they
need to understand the behavior of special variables or children().
What a beginner might see is cleaner and simpler APIs to things like BOSL2.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org