feature is

that

I'd like to pick out an example: VNFs.

"(VNF) holds the data used by polyhedron() to construct objects: a
vertex list and a list of faces."

So currently it's a 2-element list, we have functions:

function vnf_vertices(vnf) = vnf[0];
function vnf_faces(vnf) = vnf[1];

What if numerical indices of an object were instead the fields of an
object in the order they're given? Then you could change the following
line (which is creating a vnf right now)

[face, [faceidxs]]

with

new_vnf(face,faceidxs)

and all user code would continue working (provided new_vnf() calls
object appropriately) in between that's referencing by index.

Numbers aren't valid identifiers anyway, so you aren't losing much
besides having keys be numerical.

Then, all receiver functions can have a cast_to_vnf(maybe_vnf) =
is_object(maybe_vnf,... what defines vnf class?...) || assert(...)
new_vnf(maybe_vnf[0],maybe_vnf[1]);

Then in some years it can be ripped out or use an option flags to skip
check efficiently?

====================

I assume this is done for efficiency and implementation reasons, but
this precludes having OO inheritance and makes it much more of a
record than an object.

====================

All other "special" $-variables are dynamically scoped. I do not think
the dollar sign should be used, as this is statically scoped. These
methods would all be new, so having the an implicit local variable
this should be backward-compatible (just like I can override circle
today).

On 8/15/2025 5:07 AM, Cory Cross via Discuss wrote:

I'm not really comfortable with that, but I can't really articulate
why.  I think of objects as unordered; I made them have some order only
because I didn't like the presentation when echo() displayed them in
random order.  But once it has an order, I can't articulate why we
shouldn't document and use that order.

I'd like objects to allow non-string keys in the future.

As they are immutable, you can't tell the difference.

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.

Check out the discussion in PR#6022.  Neither has exactly the right
scope, and there are some tricky cases.

On 8/14/25 11:13 PM, Jordan Brown via Discuss wrote:

Hmm, I think it'd actually be simple to use as needed:

function wrap_keys(obj) =
  let ( keys = list(for(k=obj) k),
         key_vec = list(for(i=0:len(keys)-1) { [i, obj[keys[i]]] })
       ) object(key_vec,obj);

... or something close to that.

The difference is you can't have super, which ECMAScript does have.

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.

I ran an open source project for building Java/OSGi tools. We learned the hard way that the random ordering of hash maps cause many problems, primary in repeatable builds.

I think it makes perfect sense to support object[n] when n is an integer it uses it as an index.

I think you want way too much here :-) That would be a map and that is in my mind a very different beast then an object.

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. In a map you have a mapping from one value to another, which is fundamentally different. 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. I fail to see why this should be a standard feature of core OpenSCAD like object(), this is user space stuff.

The object() feature wil make this more straightforward to implement but we should imho not confuse object() with a general map. It is basically a record/struct and there is imho no reason not to index it by an integer. Especially if this makes porting easier.

Am 15.08.25 um 10:45 schrieb Peter Kriens via Discuss:

I was part of a big software project, which used Lua as main language.

In Lua there ist no difference between hashmap and array, both are just
tables (you can even intermix them).
And – YES - iterating over the key/value pairs using the pairs function
will give you random order. But it is very (!) performant.

And if you really need stable iteration, you can always (at the cost of
speed)

• get all keys from the table
• sort the keys (by any criteria you need)
• iterate over the keys and fetch the values.

We also use this for data serialisation, so even if the key order in the
table is random, saved settings etc are always stable.

We never had issues, neither in automatic test runs nor in repeatable
builds (getting bitidentical builds by commit id is essential in
embedded software for industrial use!)

Jm2C

We currently have an implementation with a hash map[key,index] and keep the values in a vector. We only add one index operation in a vector for a [key] operation. Totally negligible. I ran a profile on some BOSL2 code ... believe me this will NEVER show up in the top 10.000 even with a 100k members.

True, but wouldn't it be nicer if they ALWAYS had a consistent ordering? Your approach sounds very error prone? Why run the risk?

We had to change our code in hundreds of places. Fortunately, Java has the LinkedHashMap that provides ordering and is API compatible with HashMap but it was a huge pain in the ass because it turned out a lot of low level code could introduce random orderings that would only show up much later in the results.

BTW, Sorting would imho be wrong for this purpose. We looked at sorting because then we could use binary search. We decided on insertion order because then then the user can order as they please.  Only dilemma was when you copy an object and find the name already exists. In this case the first one wins and reuse its position.

I know!

Peter Kriens

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 go.  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 have some ideas for super, but the rabbit hole keeps getting deeper...

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

Jordan Brown via Discuss discuss@lists.openscad.org schrieb am Fr., 15.
Aug. 2025, 19:28:

On 8/15/25 10:44 AM, Guenther Sohler via Discuss wrote:

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/25 10:27 AM, Jordan Brown via Discuss wrote:

Yes.

I commented there too. For the sake of maximum audience, I'll copy my
questions/comments here:

You've got some goals and are trying to make /object/ work for them. I
think the goals are:

1. Replace hardcoded [1] and [CONSTANT] index into arrays by being able
   to name values by identifier
2. Be able to namespace functions, modules, and constants.
3. 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).

Is that correct?

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/.