Catchall proposal

[Brendan Eich]

Waldemar gave feedback

http://wiki.ecmascript.org/doku.php?id=strawman:catchalls#feedback

Waldemar's main point is a good one, which caused me to be hostile to  
catchalls for years:

  Catchalls climb the meta ladder. Primitive actions such as checking  
for the existence of a property when climbing the prototype chain can  
now run arbitrary code. This is unacceptable in some situations and  
makes the ES5 meta-object methods non-primitive, so we will need yet  
another level of such methods. It is likely to open another area for  
security attacks to hide in.

He also makes a good point about for-in, which I'll address in the  
wiki with a link to a strawman:iterators page. It could be combined  
with catchalls but I'd like to separate concerns for now.

I was planning to update the catchalls proposal to do what David-Sarah  
Hopwood suggested: brute-force split of set/setMissing, etc. for all  
the hooks. But it would be helpful to discuss a bit more here, then go  
back to the wiki. So thanks for posting.

To clarify: you are proposing two separate proposals, presumably  
meaning two API methods of Object -- defineCatchAll for missing  
properties and defineAdvice or some such for pre- and post- hooks. Is  
that right?

AOP, sigh: "before" and "after" advice for existing properties could  
be defined as a normative (i.e., mandatory to implement) part of the  
core language, but the idea with this proposal was to let the  
catchalls-using library ecosystem invent such things. Dojo, JQuery,  
etc. already have AOP support.

Catchalls are meant to be the simplest step up the "meta ladder" that  
the standard language needs to take, for the rest of the world to  
build fancier MOPS and AOP systems as they see fit.

In this light could we avoid Object.defineAdvice and provide  
Object.defineCatchAll hooks for existing properties, with a way to  
trigger default action that allows the "after" advice to be run?  
Instead of throwing a DefaultAction singleton exception, this would  
seem to want a built-in method to invoke to request the default  
action, passing a callback for the "after" hook. Comments?

/be

On May 17, 2009, at 1:17 PM, Faisal Vali wrote:

>> Subject: Re: Catchall proposal
>> David-Sarah Hopwood wrote:
> <snip>
>> To flesh this out a bit more, I propose the following handlers:
>>
>> has(id)
>> hasMissing(id)
>> get(id)
>> getMissing(id)
>> set(id, val)
>> setMissing(id, val)
>> invoke(id, args)
>> invokeMissing(id, args)
>> delete(id)
>> call(args)
>> new(args)
>>
>
> Would it be worth splitting the above into two separate proposals?
>
> Proposal #1) Hooks for only missing actions.
>
> Proposal #2) Pre/Post Hooks for existing actions.
>
> I would expect that the goals for each of the two proposals would be
> slightly different.
>
> The focus of #1 would be to enhance the run-time metaprogramming  
> facilities
>
> The focus of #2 would be to enhance the security/correctness
> (visibility, pre/post conditions, design by contract) of programs and
> support aspect-oriented programming.
>
> That way, one doesn't get mired by the other ;)
>
> Any thoughts? (i.e. are these two proposals far too intertwined to
> separate them)
>
> thanks,
> Faisal Vali
> Radiation Oncology
> Loyola
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090517/dc546e3c/attachment.html>