Better property behavior

Brendan Eich brendan at mozilla.com
Mon Dec 31 13:35:48 PST 2012


Allen Wirfs-Brock wrote:
> On Dec 31, 2012, at 10:14 AM, Axel Rauschmayer wrote:
>
>> Currently making a typo in property names can be fatal in two ways: When reading a property, things fail silently and you get back `undefined`. When setting a property, you accidentally create a new property.
>>
>> A safer behavior would be as follows:
>>
>> 1. Creating properties
>>      1a. Only property definition creates own properties.
>>      1b. Assignment throws if a property does not exist, yet.
>> 2. Reading from a property that does not exist throws an exception.
>>
>> (2) can be done by putting a proxy in the prototype chain that throws if it is reached by the search for a property.
>> (1b) can be done by making an instance non-extensible. Plus strict mode.
>> Not sure how to achieve (1a). You’d have to make all of your definitions first. But once you have prevented extensions, that would be it.
>
> 1a can also be handled by your proxy's put trap.  All it needs to do is refuse to create new properties on the "receiver" object.

Is the trap still called 'set'? Just keeping up ;-).
>
>> Does that make sense?
>
> For some new language, probably hot for JS.
>
> Perhaps you could find some utility to this technique as a debugging tool.

We've talked of two language extensions that cover this space:

* sealed classes -- a way to declare instance fields, not yet in sight, 
is needed for these, but instances would throw on typo'ed field names.

* dherman's undefined value-proxy, which traces blame back to its 
generating stack, no matter how far afield it flows before throwing 
dereference.

One could even imagine a future JS where, perhaps with macros or other 
static abstraction techniques, developers could opt into both of these 
as "defaults" for a given style of programming.

/be


More information about the es-discuss mailing list