David Bruant (2014-01-01T01:41:52.000Z)
Le 31/12/2013 20:52, Calvin Metcalf a écrit :
> I had the same idea a couple weeks ago and turned it into a library 
> https://github.com/calvinmetcalf/set.up if anyone finds it useful.
hmm... It is useful, but not future-proof. If methods with these names 
ever get standardized, your code will override them. If other code wants 
to use the standard one and there is the least semantic deviation 
between your library and the standard, this other code will break in 
subtle ways.

I'd recommand prefixing every non-standard addition with _ as in:

     Set.prototype._filter = function(func, context){
         ...
     }

This way, if a standard "filter" method arrives, your code will use 
"_filter", other code will use the standard "filter" unambiguously and 
no code will break.
This additional _ guarantees non-collision with future standard methods. 
I suggested this some time ago and no browser vendor nor standard folks 
complained too hard for this not to work, so I guess it can be declared 
author territory. The flag is up.
Note: this _prefixing trick can also work for Array.prototype and 
String.prototype and EventTarget.prototype.

David
domenic at domenicdenicola.com (2014-01-06T14:17:06.164Z)
Le 31/12/2013 20:52, Calvin Metcalf a écrit :
> I had the same idea a couple weeks ago and turned it into a library 
> https://github.com/calvinmetcalf/set.up if anyone finds it useful.

hmm... It is useful, but not future-proof. If methods with these names 
ever get standardized, your code will override them. If other code wants 
to use the standard one and there is the least semantic deviation 
between your library and the standard, this other code will break in 
subtle ways.

I'd recommand prefixing every non-standard addition with `_` as in:

     Set.prototype._filter = function(func, context){
         ...
     }

This way, if a standard `filter` method arrives, your code will use 
`_filter`, other code will use the standard `filter` unambiguously and 
no code will break.
This additional `_` guarantees non-collision with future standard methods. 
I suggested this some time ago and no browser vendor nor standard folks 
complained too hard for this not to work, so I guess it can be declared 
author territory. The flag is up.
Note: this `_` prefixing trick can also work for `Array.prototype` and 
`String.prototype` and `EventTarget.prototype`.