Adding methods to {Array,String}.prototype
On Jul 28, 2011, at 2:19 AM, Axel Rauschmayer wrote:
In general, I’m strongly in favor of adding more methods to these prototypes. I have always been impressed by how many useful data manipulation features were in the standard libraries of functional languages (e.g. Haskell) and in scripting languages such as Python. JavaScript should have more of these, perhaps by examining what functionality frameworks are providing in this area.
Do we have to wait for a collections hierarchy for more of these methods to be added? Couldn’t the relevant methods be easily moved to a superclass once that happens?
There is no superclass. Trying to make one is a bad idea. We'll end up with the usual tyranny-of-hierarchy problem where you want something to multiple inherit to be both a Collection and a Widget.
I like Underscore (documentcloud.github.com/underscore). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions.
I like Underscore (documentcloud.github.com/underscore). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions.
I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON).
On Jul 29, 2011, at 9:53 AM, Axel Rauschmayer wrote:
I like Underscore (documentcloud.github.com/underscore). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions.
I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON).
I did not mean multimethods ("generic functions" is a confusing term, since it also means functions that work for parameters of any time; also "generic" suggests "generics", i.e. type parameters).
ES4 had a proposal for multimethods but I doubt it will make a come-back. Adding another dispatch mechanism to JS is a very hard sell. For dyadic operators, double dispatch is enough.
On Jul 29, 2011, at 10:08 AM, Brendan Eich wrote:
On Jul 29, 2011, at 9:53 AM, Axel Rauschmayer wrote:
I like Underscore (documentcloud.github.com/underscore). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions.
I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON).
I did not mean multimethods ("generic functions" is a confusing term, since it also means functions that work for parameters of any time
s/time/type
Coffee time!
I like Underscore (documentcloud.github.com/underscore). Should we standardize it? Not yet. But it points in the right direction to avoid OOP single-inheritance traps: functional programming, generic for all containers functions.
I love true generic functions (as in “multiple dispatch”) and think that they would be a good match for JS (not any time soon, but one can dream). I see generic functions as complementary to single dispatch (including prototypes). Reenskaug and Coplien [1] seem to agree. Generic functions are also great for working with data coming from web services (e.g. JSON).
I did not mean multimethods ("generic functions" is a confusing term, since it also means functions that work for parameters of any time; also "generic" suggests "generics", i.e. type parameters).
Understood, but generic functions (the way that Common Lisp and Dylan use that term) are a logical extension of JavaScript’s generic functions (the way ES-262 uses that term). Right now, JS generic functions have implicit contracts that one could make explicit (e.g. via some kind of duck typing). Type guards also seem loosely related.
ES4 had a proposal for multimethods but I doubt it will make a come-back. Adding another dispatch mechanism to JS is a very hard sell.
Right. That’s where my dreams come in. ;-)
On 29 July 2011 19:08, Brendan Eich <brendan at mozilla.com> wrote:
I did not mean multimethods ("generic functions" is a confusing term, since it also means functions that work for parameters of any time; also "generic" suggests "generics", i.e. type parameters).
"Generic" is a heavily overloaded term. I forgot who said it, but I remember a quote along the lines of "by `generic' people always refer to the sort of polymorphism that your favourite language doesn't have".
In general, I’m strongly in favor of adding more methods to these prototypes. I have always been impressed by how many useful data manipulation features were in the standard libraries of functional languages (e.g. Haskell) and in scripting languages such as Python. JavaScript should have more of these, perhaps by examining what functionality frameworks are providing in this area.
Do we have to wait for a collections hierarchy for more of these methods to be added? Couldn’t the relevant methods be easily moved to a superclass once that happens?