Non-string keys strikes me as overkill and wasted effort. I’m sure one can come up with cases where it might seem “cool”, or elegant. But it will not produce easy to understand and maintain code. I would much rather write 10 lines of code that are immediately intuitive than 4 lines of clever elegant code. I might enjoy the clever elegant result, but when I return to that code in 4 months or 4 years I will, much prefer the easily understood version. -Bob > On Aug 27, 2025, at 07:49, Jordan Brown via Discuss <discuss@lists.openscad.org> wrote: > > On 8/27/2025 4:04 PM, Peter Kriens via Discuss wrote: > >> The current object treats objects as a list of strings. I.e. the comprehension is over strings and you need to look up the value by string. I wonder if we should make it a list of values instead. This gives us less API breakage if we start supporting maps with other types of keys then strings. > I don't know what the exact status is today, but I intended to make it reject non-string keys, to allow for arbitrary-type keys in the future. And indeed object() rejects non-strings as keys. > > So while strings are the only thing that you can use today, a future version could allow other types. > > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org

Revar's code isn't "cool"; it is *much* faster due to lookups being O(1) using objects. It would in fact be much easier to read and maintain, and far more intuitive, if Revar didn't have to munge triples of numbers into strings to put them into the objects. So you're actually completely backwards about the situation here with regards to code comprehensibility and maintainability. Generally speaking, if the stuff you want to store is naturally indexed by numbers, being forced to turn them into strings is NOT the clever and elegant approach, it's the clunky, messy approach that's going to be harder to read in 4 years. The code in BOSL2 for screws has lookup tables that look up things like "#8" for a screw size but also 1/4 (e.g.a 1/4-20 bolt). The current implementation is clean and simple written like that (using BOSL2 struct.scad) with strings and numbers. If it's done directly in strings alone what happens to the size 1+1/8? It now has to have a unique representation as a string instead of any way to write 1 1/8. So would that be 1.125? Or 1 1/8? 9/8? Or do I need an implementation that works like what I have but a final step that converts numbers to strings in a canonical way? Nothing simpler or more comprehensible about that either. On Wed, Aug 27, 2025 at 8:08 PM Bob Carlson via Discuss < discuss@lists.openscad.org> wrote: > Non-string keys strikes me as overkill and wasted effort. I’m sure one can > come up with cases where it might seem “cool”, or elegant. But it will not > produce easy to understand and maintain code. I would much rather write 10 > lines of code that are immediately intuitive than 4 lines of clever elegant > code. I might enjoy the clever elegant result, but when I return to that > code in 4 months or 4 years I will, much prefer the easily understood > version. > > -Bob > > On Aug 27, 2025, at 07:49, Jordan Brown via Discuss < > discuss@lists.openscad.org> wrote: > > On 8/27/2025 4:04 PM, Peter Kriens via Discuss wrote: > > The current object treats objects as a list of strings. I.e. the > comprehension is over strings and you need to look up the value by string. > I wonder if we should make it a list of values instead. This gives us less > API breakage if we start supporting maps with other types of keys then > strings. > > I don't know what the exact status is today, but I intended to make it > reject non-string keys, to allow for arbitrary-type keys in the future. > And indeed object() rejects non-strings as keys. > > So while strings are the only thing that you can use today, a future > version could allow other types. > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org