Expected behavior when referencing undefined field of object?
Quick question about the (relatively) new and experimental object feature -- what is the expected behavior when referencing an undefined field?
Right now the final pair of echos print "undef":
x = object([["abc", 123]]);
// These all work as expected
echo(x.abc);
echo(x["abc"]);
// Should these fail?
echo(x.def);
echo(x["def"]);
While I can catch this in my code, I was surprised to find that the references did not raise an error. I did RTFM and the discussion and could not find this documented or debated either way.
Thanks,
Jeff;
On 11/25/2025 2:01 PM, Jeff Barr via Discuss wrote:
Quick question about the (relatively) new and experimental object
feature -- what is the expected behavior when referencing an undefined
field?
Yields undef.
While I can catch this in my code, I was surprised to find that the
references did not raise an error. I did RTFM and the discussion and
could not find this documented or debated either way.
Oops. I've added a sentence to the section on retrieving values from
objects.
I stole the semantics from JavaScript, where an undefined member
yields undefined, rather than Python where it yields a KeyError error.
Partly that's because I've written enormously more JS than Python and so
that's the semantic I'm more familiar with. In JS, that yields simple
idioms like (obj.mem || "default") to get a default value, rather than
needing the more complex ('mem' in obj ? obj.mem : "default"). However,
since OpenSCAD doesn't have JS semantics for ||, you're still stuck
with (obj.mem ? obj.mem : "default").
(And yes, because of falsiness semantics JS's || is an imperfect way to
get defaults... but it's good most of the time.)
Anyhow, I'm not morally opposed to the Python semantic; if people
overwhelmingly prefer it, I'm OK with switching.
In Openscad, foo[x] gives undef when x is out of bounds. It seems like
this means that obj["notvalid"] needs to also produce undef for language
consistency.
On Tue, Nov 25, 2025 at 7:14 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 11/25/2025 2:01 PM, Jeff Barr via Discuss wrote:
Quick question about the (relatively) new and experimental object feature
-- what is the expected behavior when referencing an undefined field?
Yields undef.
While I can catch this in my code, I was surprised to find that the
references did not raise an error. I did RTFM and the discussion and could
not find this documented or debated either way.
Oops. I've added a sentence to the section on retrieving values from
objects.
I stole the semantics from JavaScript, where an undefined member yields
undefined, rather than Python where it yields a KeyError error. Partly
that's because I've written enormously more JS than Python and so that's
the semantic I'm more familiar with. In JS, that yields simple idioms like (obj.mem
|| "default") to get a default value, rather than needing the more
complex ('mem' in obj ? obj.mem : "default"). However, since OpenSCAD
doesn't have JS semantics for ||, you're still stuck with (obj.mem ?
obj.mem : "default").
(And yes, because of falsiness semantics JS's || is an imperfect way to
get defaults... but it's good most of the time.)
Anyhow, I'm not morally opposed to the Python semantic; if people
overwhelmingly prefer it, I'm OK with switching.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I concur.
-Revar
On Nov 25, 2025, at 4:37 PM, Adrian Mariano via Discuss <discuss@lists.openscad.org> wrote:
In Openscad, foo[x] gives undef when x is out of bounds. It seems like this means that obj["notvalid"] needs to also produce undef for language consistency.
On Tue, Nov 25, 2025 at 7:14 PM Jordan Brown via Discuss <discuss@lists.openscad.org> wrote:
On 11/25/2025 2:01 PM, Jeff Barr via Discuss wrote:
Quick question about the (relatively) new and experimental object feature -- what is the expected behavior when referencing an undefined field?
Yields undef.
While I can catch this in my code, I was surprised to find that the references did not raise an error. I did RTFM and the discussion and could not find this documented or debated either way.
Oops. I've added a sentence to the section on retrieving values from objects.
I stole the semantics from JavaScript, where an undefined member yields undefined, rather than Python where it yields a KeyError error. Partly that's because I've written enormously more JS than Python and so that's the semantic I'm more familiar with. In JS, that yields simple idioms like (obj.mem || "default") to get a default value, rather than needing the more complex ('mem' in obj ? obj.mem : "default"). However, since OpenSCAD doesn't have JS semantics for ||, you're still stuck with (obj.mem ? obj.mem : "default").
(And yes, because of falsiness semantics JS's || is an imperfect way to get defaults... but it's good most of the time.)
Anyhow, I'm not morally opposed to the Python semantic; if people overwhelmingly prefer it, I'm OK with switching.
_______________________________________________
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
On 11/25/2025 4:37 PM, Adrian Mariano via Discuss wrote:
In Openscad, foo[x] gives undef when x is out of bounds. It seems
like this means that obj["notvalid"] needs to also produce undef for
language consistency.
Huh. So it does. I remembered it giving an out-of-bounds warning and
then undef. I don't know where I got that. (Maybe it did for a while?)
And yes, that fact does push for an undefined object member yielding undef.