Wouldn't being bolder on new constructs save the "breaking the web" costs for future"?

Herby Vojčík herby at mailbox.sk
Tue Jan 8 04:55:18 PST 2013



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


More information about the es-discuss mailing list