>-----Original Message-----
>From: Brendan Eich [mailto:[email protected]]
...
>my "Art of the Meta-Object Protocol" is in a box somewhere for a
>reason ;-). But real-world use-cases are pressing upon us.
>
I dug mine out after the last F2F, it's been sitting on my desk unread since...
>
>> A simpler model would only have these handlers
>> assign called on any explicit assignment to a non-existent
>property
>
>Still does not connote "non-existent".
If all these handlers are only invoked in missing property situations then we
can probably get away with an implicitly non-existent connotation.
...
>
>> delete delete a non-existent property
>
>Sure (hard to care about this case), but the ability to use catchalls
>to emulate arrays may be an important use-case for virtualizing
>systems. If delete can't be handled for existent properties then
>length can't be updated.
>
So, maybe delete falls into a different category of handlers (perhaps along
with invoke and construct on the object itself, defineProperty, etc...) that
aren't about non-existent properties but are hooks on important object level
meta operations (at MOPish step but it keeps the catch all story cleaner).
>
>> getValue called on any implicit or explicit non-existent
>property
>> access to that is not one of the above
>
>What is an implicit property access other than the above? I added
>"has" because property lookup does not getValue, and must not, but
>unless you ignore catchalls on the global object and objects named by
>with statement heads, you need "has" too.
>
I hadn't thought through "implicit" but I was at least thinking about accesses
from built-ins. I would also expect that getValue (and the others) would need
to work on implicit accesses to the global object or a with object. With
lookup might be trickly but I think it could be probably be make to work at
least in the specification. It might be necessary to make DefaultAction
contextual so that it does something different when trying to resolve a with
binding
>
>> At most one of the above is called on any property reference, and
>> only if the property does not exist.
>
>Besides making it impossible to virtualize arraylikes, this will make
>virtual DOMs hard to implement efficiently.
Is there anything other than the delete hander that is needed to emulate
arrays? What is the DOM problem?
...
>
>So perhaps invoke could be for non-callable (including non-existent,
>i.e., imputed-undefined-value) properties.
>
I have some similar concerns about assignments to readonly properties and
perhaps other error conditions. Maybe they are error handlers.
On a complete different plane, here is a wacky idea that integrates this work
into Object.defineProperty:
Object.defineProperty(obj, undefined, {invoke: function(id, args) {...},
...});
Keeps the API surface smaller and emphasizes that this is really an way to
define the handling of otherwise undefined properties.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
