On Nov 12, 2007, at 1:43 PM, YR Chen wrote:
On Nov 12, 2007 11:40 AM, Mark Miller <[EMAIL PROTECTED]> wrote:
On Nov 12, 2007 9:05 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> [..], but the idea would
> be to enable throwing of a ReadOnlyError on assignment to a ReadOnly
> property. Comments?
Hi Brendan,
I'm glad to hear that this possibility is in scope. In the Caja
spec, we write:
\item[Silent errors.] In JavaScript, various operations, such as
setting a
ReadOnly property, fail silently rather than throwing an error.
Program
logic then proceeds along normal control flow paths premised on the
assumption that these operations succeeded, leading to inconsistency.
Out of curiosity, what other JS operations fail silently?
Nothing as badly silent as assigning to a ReadOnly property, but here
I'll bitch about a similar change during ES1 standardization: delete
x => false if x is in the scope chain but bound with the DontDelete
attribute -- otherwise delete x => true, either if it was found
without DontDelete and therefore deleted -- or just not found! So
delete asdfewr => true. Same for any more qualified reference, e.g.
delete foo.bar when you mean foo.baz. Oh, and if bar was found in a
prototype object of foo, delete foo.bar => true without doing anything!
This all seems wrong, and IIRC in Netscape 2, JS1, the original buggy
progenitor language, delete would report an uncatchable error on bad
inputs. Just as assigning to ReadOnly would. Someone with an old PC
and Netscape 2 or 3, please confirm.
I forget why I gave this up in committee. Lot of horse-trading back
then to get to ES1.
Anyway, with exception handling these both seem like warts. At least
with delete, the expression using that operator at the top level has
a boolean result -- but the result could be true and the property is
still "in" the object (via prototype-based delegation). Beware.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
