Assigning to ReadOnly properties
brendan at mozilla.org
Mon Nov 12 14:30:56 PST 2007
On Nov 12, 2007, at 1:43 PM, YR Chen wrote:
> On Nov 12, 2007 11:40 AM, Mark Miller <erights at gmail.com> wrote:
> On Nov 12, 2007 9:05 AM, Brendan Eich <brendan at mozilla.org> 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:
> setting a
> ReadOnly property, fail silently rather than throwing an error.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss