Brendan Eich wrote:
You are describing path dependency, which afflicts us all, in various
evolving systems including JS.
We cannot keep resetting ES6 to include and think through and make
consistent things such as nil. Sorry, that trades off badly against
developers' time -- they need the good stuff coming already in top
engines, which Allen is drafting.
If you would explain this better, I'd be glad - it is too dense for me
to understand (especially "include and think thorugh" and "they need the
good stuff ..."). Thanks.
And since we're only human, along the dependent paths we walk, missteps
happen. If we can back up and take a better path in time for ES6, we will.
I understand there is a legacy, but I am deeply convinced there is
hardly better path through which fix(es) can be made than through new
construct. Because old ones must work as expected.
Another thing we try to do: make incremental progress edition by
edition, based on experience ("pave the cowpaths", lessons from nearby
languages, championed designs that are prototyped early, e.g. proxies),
but not close important doors. This is called future-proofing.
What are those "champions" and "championed" you use in meeting notes
often? Thanks again. :-|
Your desire to make class object identity !== class constructor function
identity could be viewed as future-proofing, but we have to pick some
Exactly (and with nil as well, though there it is a bit weaker; the
whole OP was about "fix&future-proof" combo).
identity for ES6. And again, apart from the need to separate constructor
"some [non-tied] identity" I'd say, when the proposal is about making
those identities separated. That's why I proposed (as a general, first
step) the most general thing - a plain Object. As a most general one, it
is most future-proofing.
invocation via () from invocation view new, we don't have strong
motivation to future-proof.
Hm.
What exactly is "future-proof"? How does it relate to "enough space for
new cowpaths" and "progress"? These things are really mixing in my head,
probably because they really are somewhat intertwined.
If future-proof is really _only_ about "Just don't make this impossible,
eventually", that is, if it is about preventing unnecessary constraining
(eg. when existing things are fixed / specced better) a specific known
use case is probably good enough as a criterion whether to future-proof.
But I think this is not a case for future-proof which is combined with
additions (not updates). Additions invlove those "new spaces for
cowpaths". There, you cannot (I think) use some specific use case as a
criterion, because you don't know where and how the cows will walk.
So I wonder if it is more a future-proofing or opening the gates? I am
saying that class !== constructor proposal is not just a
future-proofing, it's 'open the gates to use plain objects as classes"
combined with future-proofing "any (normal) object can be, eventually,
used within new / extends, the user chooses".
I'd like to ask my question on the original post again, sorry. If there
is "future-proof" combined with "new space for cowpath" possibility and
it can be brought in with the new feature, is it not worth considering,
given that it cannot be done later when new feature will be stuck with
already given, probably inherited from legacy, semantics?
However I see at it, it more than future-proofing. It is
future-proofing--model-evolution--only-t6-be-efficiently-done-now.
I was asking on such combos. Or I see it wrongly? I am really deeply
convinced that once class will produce legacy class===constructor
pattern, no [[Constructor]] freeing can ever happen because there will
already be code that uses class and exploits that fact; the same is for
existential operator not returning nil - later it cannot be switched.
It's easy to wrap up your own designs along neater lines that themselves
Yes.
have lots of dependencies (nil in language is controversial, from my
twitter survey -- it arguably hides errors). Mature language design,
Yes, it hides. :-/
really all successful language design however radical, shies away from
running ahead along one path too far, at least in the "main line". That
would be ECMA-262, so ES6 ;-).
Would changing [[Construct]] semantics for `class` (at least half a
step) to clearly follow .prototype.constructor being a "too far ahead
one path"? It gives free new/super consistency and free default
constructors (and insight into class/constructor separated worldview)?
I don't consider even the real class/constructor separation too far
ahead, it is little well-placed design change (in a new construct).
/be
Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
