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

> 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...


> > [...]
> > 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. 

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.



> 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.



> > I cannot agree on that. Firstly, using an underscore is ugly.
> Bikeshed :-)

Ok now I've been caught bikeshedding I can safely describe what my latest practices are. My current practice when extending the DOM in a speculative way is to prefix my functions with "my" possibly followed by a library name if I think it's worth (ie: there's a non-zero risks of conflicts).

Examples: 
- window.myQuerySelectorLive(...)
- myDOMRange.myMoveOneCharLeft()
- array.myFremyFind(...)
- ...

I don’t do that every time when I extend the global namespace with sub-namespaces however, because I believe the risk of conflict is sufficiently low, or when I extend objects I define myself in the library.

Counter examples:
- window.cssCascade.getSpecifedStyle(...)
- (but: new window.myTasks.TaskScheduler(...))
- ...



> > 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.



> 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, you're in trouble but with unique name you're still fine if the two polyfills do not block each other (in the case of simple ones, this is usually the case).

Received on Sunday, 18 August 2013 17:01:52 UTC