Scoped binding of a method to an object

David Bruant bruant.d at gmail.com
Sun Oct 13 11:41:14 PDT 2013


Le 13/10/2013 20:29, Benjamin (Inglor) Gruenbaum a écrit :
> David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote
> > This proposal does not aim at solving the problem of library 
> conflicts which existed before this proposal and should be solve 
> independently.
>
> Of course, and I'm sorry if I implied otherwise. I'm sure we all 
> acknowledge the problem of extending the native prototypes in 
> libraries. I just don't understand how having a `_` prefix attempts to 
> give us a solution to the problem. I'm not saying I have a solution 
> either, but I think implying that it's ok to extend them with a prefix 
> doesn't really solve much. Maybe I got what you were trying to say 
> wrong though.
Not wrong, but partial ;-)
'_'-prefixing isn't a solution in itself. It requires a commitment from 
the platform to say they won't make use of this namespace in the future, 
thus allowing authors to use this namespace without worrying about 
future conflicts.

Just to clarify a point, I started speaking about _-prefixing after 
Till's point about "the language's builtins library ability to evolve". 
My point is somewhat unrelated to scoped binding and is not a solution 
for that (I should fork the thread if we continue discussing this).

David

>
>
>
>
> On Sun, Oct 13, 2013 at 9:25 PM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 13/10/2013 20:03, Benjamin (Inglor) Gruenbaum a écrit :
>>     David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
>>
>>     > Concretely, attempted prolyfills, could be _-prefixed (that
>>     really fits with what you call "poor-man's prefixing", I believe)
>>     > Authors would feel free to add something like
>>     Array.prototype._shuffle or Array.prototype._last, or
>>     EventTarget.prototype._on without worrying about collision with
>>     the platform.
>>
>>     What if I use two libraries that polyfill `_shuffle` or `_last`
>>     differently (let's say with different behavior for an empty array
>>     for `_last` or weaker guarantee on the randomness in `_shuffle`)?
>     What do you do today when a library overrides
>     Array.prototype.concat with a different semantics?
>     What do you do when you load two libraries each defining a global
>     $ with different semantics?
>
>     Apply every prevention/resolution mechanism you use today with
>     global properties. Among other ideas:
>     * don't load libraries that are known to have conflicts (!!)
>     * isolate the code that enhance built-ins (preferably, run it
>     before anything else and not in the middle of your application
>     lifecycle)
>     * Define functions as non-configurable/non-writable in development
>     mode to discover conflicts before pushing to production.
>
>     This proposal does not aim at solving the problem of library
>     conflicts which existed before this proposal and should be solve
>     independently.
>
>     David
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/928c70c3/attachment.html>


More information about the es-discuss mailing list