E-on-JavaScript property mapping: fail on nonexistence?

View: New views
3 Messages — Rating Filter:   Alert me  

E-on-JavaScript property mapping: fail on nonexistence?

by Kevin Reid-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

In E-on-JavaScript, when in Cajita mode, object["foo"] accesses the  
foo property of object. Should it throw if the property does not  
exist, or return JavaScript undefined as occurs in JavaScript?

--
Kevin Reid                                  <http://switchb.org/kpreid/>




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: E-on-JavaScript property mapping: fail on nonexistence?

by David-Sarah Hopwood-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Kevin Reid wrote:
> In E-on-JavaScript, when in Cajita mode, object["foo"] accesses the  
> foo property of object. Should it throw if the property does not  
> exist,

Yes. It's E-on-JavaScript, so E's philosophy about avoiding silent
failures applies. Cajita would throw if not for the constraint of
being a fail-stop subset of ECMAScript.

> or return JavaScript undefined as occurs in JavaScript?

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: E-on-JavaScript property mapping: fail on nonexistence?

by Mark Miller-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Aug 23, 2009 at 1:12 PM, David-Sarah Hopwood <david-sarah@...> wrote:
Kevin Reid wrote:
> In E-on-JavaScript, when in Cajita mode, object["foo"] accesses the
> foo property of object. Should it throw if the property does not
> exist,

Yes. It's E-on-JavaScript, so E's philosophy about avoiding silent
failures applies.

I agree.
 
Cajita would throw if not for the constraint of
being a fail-stop subset of ECMAScript.

Actually, that would be allowed within the definition of fail stop. However, we don't because the "feature testing" pattern -- "if (foo.bar) { foo.bar(...); }" is way too common, and, like a failed side effect, a read resulting in an undefined is likely to be noticed. This is the same reason that ES5-strict chose not to throw for failed reads but does throw for many other failures.

--
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang