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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
