On 14.10.2010 19:38, Brendan Eich wrote:
On Oct 14, 2010, at 7:54 AM, Dmitry A. Soshnikov wrote:
On 14.10.2010 4:14, Brendan Eich wrote:
On Oct 13, 2010, at 6:56 AM, Dmitry A. Soshnikov wrote:
Also I think now, that what was named as pros, i.e. ability to have funargs and
call/apply invariants, in real, not so pros. Because users more likely want to catch
exactly missing methods (if you don't like the word "methods", since there're
no methods, there are properties, let's say -- missing properties which ended with `call
expression` at the call-site).
That's not our experience with E4X (ECMA-357), which specifies XML methods as
invoke-only. They seem to be normal function-valued properties of
XML.prototype, but getting one by name on an XML instance in a non-callee
expression context instead tries to find an XML child element or elements of
the method's name, returned as a list.
Some of this is peculiar to E4X, but the invoke-only nature of the methods,
per-spec, is not. And it breaks apply and functional programming, so we
extended E4X with the function:: pseudo-namespace to allow one to extract
methods from XML instances.
Yes, I'm aware of it. However, you mention a similar end result (inability to
extract a function with a normal (accessor) syntax), but with completely
different reason. In case of EX4 you talk about the existing real methods. In
case of proxies, we talk about non-existing property (which is activated with a
next call expression).
Stop right there -- I think you are assuming you conclusion, or favored outcome.
For proxies we want users to reify real function objects (or function proxies
which are equivalent). Not reify nothing on get, making the methods invoke-only
phantoms. We are disagreeing on the premise that invoke-only methods are better.
Well, if "on the premise" -- what can I say? -- then the main task is to
find the solutions and fix all broken invariants.
It seems to me you favored invoke-only methods because the code to implememnt them (using
__noSuchMethod__, an invoke trap, or even a get third argument telling context) was
"simpler". Not because you wanted invoke-only methods _per se_. Please clarify.
Of course. I'm absolutely not against if the missed methods will be real
functions. Of course it's not per se that I want phantoms. "Phantoms"
are just acceptable "implementation tax" to avoid all mentioned broken
invariants. The tax is -- there are no funargs/apply. The tax is less
than in case of broken invariants.
I do not think invoke-only methods are a feature in any case, ignoring
implementation costs of __noSuchMethod__ vs. Proxies.
It's not versus. As I already mentioned and repeat it again -- I'd like
to have noSuchMethod _in addition_ to other methods of a proxy handler
(but not instead of proxies) . It still the proxies, just have
additional method which handles (I repeat again) -- the _case_, the
_situation_ of missing a property (this is how it's possible to justify
phantoms -- the user deals not with a method, but with a _fact_, with
the _situation_ of missing; And to handle this situation, he has a hook;
from this viewpoint, possibly the user does not need a function itself).
But of course, if it's possible to have at the same time real functions
and avoid broken invariants -- it'd be the best way. If there will be
broken invariants -- no one needs such implementation. If it will be
needed to write a huge code just to have noSuchMethod -- no one will be
glad. Of course, if this huge code of fixing broken invariants will be
abstracted and encapsulated from a user, then it's OK. But it's not.
So of course, I think that additional noSuchMethod will be simpler. And
simplicity/shortness of the code is one of the main features.
The difference is: in first case a user really deals with existing stuff and
expect the functions to be extracted (of course in this case ECMA-357 had to do
something -- provide :: -- to allow this)
(No, that was our function:: extension -- E4X leaves these XML prototype
methods invoke-only on XML instances.)
Oh, I see.
. In the later one, at the first place, a user wants to catch the call
expression.
Does the user really want *only* this? Or might it be "simpler" to hack with
__noSuchMethod__, but the user would ideally want get to reify a function that could be
passed around, invoked later, etc.?
I argue the latter is what users want if they think about it,
But (once again) I do not propose use _just_ noSuchMethod. I propose it
as _addition_. And I already repeated not once -- still the _whole
scheme with get+fn is still here_. We may even write a best-practice
note that there should be used this and that (get+fn), with describing
all the cases, with providing codes for caching/invalidating
cache/deleting/etc. And near, just a small note -- "or, if you don't
need funargs, you may use noSuchMethod hook of a proxy" (without
promoting, without even examples, without everything, just a small note,
that this hook is). And the we'll see what users will choose mostly.
or get to the point of purveying their invoke-only methods to most JS hackers,
who do use partial application (apply via a helper function on a funarg), and
so forth. Prototype, JQuery, etc. are full of such code. It will break badly on
invoke-only methods.
Yes, true. But repeat, we have to solve all broken invariants if on the
premise there should no be _additional_ noSuchMethod hook for proxy
handlers.
This is something we should agree or disagree on before going further.
I see (and described before) current pros and cons of both approaches.
With my approach we have first+second, with first -- only first. Of
course I agree that it'd be good to have them as funargs. But if the
price is -- inconvenience and broken invariants -- I choose not to use
missed funargs then.
Still: try to see on it not as using a function (there is no function!
it's missed), but as _handling the situation_ (the situation of missed
method). Then noSuchMethod is quite logical hook.
Plus, I'm out of time to reply to the rest of your lengthy message. More when
I can,
Unfortunately, me too. I'll answer on Tom's and your second letter later
(today is already night here, going to seep). I read them, glad that
some broken invariants became more clear after the detailed explanation
and glad to see some code for handling it. But still I need to clear
some things, so we'll do later.
Dmitry.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
