T.J. Crowder wrote:
On 1 June 2012 00:51, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Dave's cascade proposal:
http://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/
Thanks. With a great deal of respect, I'm not seeing how that isn't
"with-lite" with a magic LHS. Indeed, how is it less confusing (and
less implicit) than the existing `with`? Re the recurring array
example: Which `pop` is it? One specific to the object?
Yes, and only that.
A local?
No. This is a special form, the expressions you can cascade in the {}
are restricted. The leading identifier is always only a property
reference in the head object.
Something in the containing scope?
Nope.
A global?
No way ;-).
Why is the magic constrained to the LHS?
Because that's the intended useful magic. This is a new special form, as
Mark pointed out for factoring
o.foo = 1;
o.bar = 2;
o.baz()
into
o.{foo = 1; bar = 2; baz()};
(I squished on one line here.)
I believe it's a mistake to theory-patch, however. You were
following the reform-with path which leads to leading dot. Then
the ASI (lack of it, as usual -- "nega-ASI" :-P) problem reared
its head. Then you mooted ~. This approach has a smell, in science
and engineering. I say this without meaning offense again, since
I've done it myself (especially in code, so there's a code patch
too -- and technical debt if not a user-facing "noise" spike).
I'm not seeing (smelling?) a smell.
Theory patching analogue: add a funny but unambiguous character before
the . to rescue the reform-with theory. But you agree we're not
reforming 'with' and Dave's cascade syntax has nothing to do with 'with'
(see above).
Making free symbols be implicit property lookups has an error-prone
history (vis: `with` as-was),
Only if those free symbols are looked up in the scope chain to which the
'with'-head object has been prefixed. There is no hazard in a shorthand
derived from good old dot.
so my thought was: Make it explicit. I'm not by far the first. Dave
pointed out that ASI causes an issue with the specific syntax I
mentioned, so I addressed that -- while making the point that the
specific syntax was not the main thrust of the argument. Surely we can
respond to reasonable syntactic flags without invalidating the broader
concept?
No, we do not agree on what you call the "broader concept". Let's settle
that first before syntax arguments.
The theory does not need a ~ patch if there is no 'with' hazard. Dave
defined the proposal so that there is not. Are you concerned that there
is an appearance of a hazard, due to
obj . { foo = ...
(I spaced things out and left off the right context on purpose). IOW,
because if one ignores obj and the dot, we have what looks like a block,
which starts with what looks like a free variable reference, foo?
I get that. It's why I argued for () instead of {}. But this is a
readability or usability issue, so again I wouldn't try patching with
leading ~. under the {} bracketing. And note that it's not a 'with'-like
situation in any case -- no scope chain lookup (only what might be the
appearance of that).
All of which is somewhat beside the point. The main point is that it
seems like the object extension literal proposal (esp. when combined
with the cascade proposal) is another form of `with`, with similar
issues, plus some confusion with object initializers.
Let's be precise. You keep bringing 'with' up but it's not relevant to
the cascade proposal, going by Dave's definitions. If you have the
"appearance of 'with'" concern I call out above, let's argue about that.
It's a good one (again it is why I preferred () a day or so ago).
My main point is: Perhaps the issues arising are in part because of
the magic, and perhaps either A) Making it explicit helps, or B) The
magic ain't worth it.
(B) certainly could be the case. Deciding is art not science.
(A) is not constrained to be ~. or any such prefix if the problem is
"appearance of 'with'" even thought this new special form was designed
not to extend the scope chain. We should argue about the predicate
problem, not about explicit patches to fix it.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
