Re: Non-agression pact for the JS runtime namespace territory

Le 18/08/2013 19:01, Francois REMY a écrit :
>> Note that for libraries and user code, independent properties
>> or Array.prototype, etc. can be made immutable preventing
>> unexpected changes. That can be enough at dev time to notice
>>   any conflict between 2 libraries.
> This is a great way to notice the problem, but then you've yet to fix it if you want both libraries and they rely on a different implementation of "myObject.doSomething(...)" in their codebase...
The problem exists anyway and has to be solved anyway, but that's beyond 
the point of this thread.

>>> [...]
>>> I think the language would be in a much better
>>> shape to deal with the naming issues if it did
>>> support "obj.[key]" as an alias to "obj[key]".
>>  From all of that, it seems that we agree unique
>> strings/symbols aren't as practical for what they're
>> intended as we wished.
> Yes, but my point is that we can fix that. I can totally see it would be practical to use them 3 years from now in combination with a good ES7 transpiler/autocomplete, which I believe TypeScript will be, given some minor tweaks to the language.
When you say "minor tweaks to the language", you referring to 
ECMAScript? Submit your proposal to es-discuss now, these things take 
time usually ;-)

> If your point is that we should not pursue this approach anymore, I don't agree. If your point is that we should pursue a simpler approach in the meantime, I think I can agree.
I guess my point is that I had not fully understood yours :-p
Could you reformulate https://gist.github.com/DavidBruant/6256883 with 
your ES7 transpiler-based implementation strategy? I feel an example 
will make things much clearer.

In any case, although I wish I could agree with you, I think toolings 
like TypeScript are not widespread enough yet and I think it's fairly 
ambitious to say a problem can be solved assuming changes to ECMAScript. 
I would love to see this, but I'm doubtful.

>> Specifically, if we can ever have at least both
>> Chrome and Firefox devtools showing a warning
>> anytime devs don't do something agreed upon
>> here, that'd be a good step forward.
> Given there's a legit use (polyfills) they are unlikely ever doing that.
Polyfills typically check whether there is a native version already in 
place, so they shouldn't trigger the warning.
We can have the warning in old browsers implementing the warning and not 
implementing the polyfilled feature. It seems like an odd case. Should 
we care?
In any case, humans can also ignore the warnings when they know they 
define a polyfill. It's a case of false positive, but not really a big deal.
My goal here is making the situation better, not solving the problem 
perfectly.


>>> Secondly, it doesn’t solve cross-library prefixing.
>> As I said above, this isn't the problem being solved here.
>> Webdevs need to figure this one out without the
>> involvement of browsers.
> I think solving one without the other is even harder, because you want webdevs to constraint themselves to make your life easier without much yields for them. But that's only my point of view, I may be wrong.
You seem to oppose me ('your life') and webdevs... I don't really know 
why: I'm a webdev.
The benefit for webdevs is making sure their libs won't break over time. 
I believe there is some value in knowing that things you define in a lib 
will *never* conflict after a browser update.
I don't think devs are really happy to see their websites broken because 
of browser updates. If some level of guarantee can be provided, that's a 
good step forward.
With browser warnings, risks for future breakages in an existing can be 
easily identified. That's not nothing.

"you want webdevs to constraint themselves"
=> We've seen what happens when both browsers/specs and webdevs do 
things unconstrained (websites break, lots of back and forth between 
browser bug trackers and specs). I haven't considered the option of 
asking browsers/specs to constraint themselves because I believe it's 
doomed to fail; If you want to try, be my guest and prove me wrong :-)
So I guess constraining webdevs is the last idea. I've tried to think of 
the simplest constraint. If better ideas emerge, I'm all for it.
I want to solve the problem, not promote my solution at all cost.

>> For a prollyfill, what's the benefit of a unique string over a prefixed property?
> Dependencies. Library A relies on prollyfill A and Library B relies on prollyfill B, both of which represent different versions of the spec but have some conflicts. If they use a simple prefix
No one prevents them to sub-namespace after the prefix. How is this 
problem solved today? Just apply the same solution but with an 
additional prefix.

David

Received on Sunday, 18 August 2013 17:39:48 UTC