Do modules make "static" unnecessary?
On Jul 1, 2013, at 7:23 AM, Juan Ignacio Dopazo <dopazo.juan at gmail.com> wrote:
So, in the light of modules, are "static" methods necessary?
Static methods that use the |this| value to allow for constructor-side inheritance don't work correctly if simply imported from a module.
See Array.from and Array.of for an example of this in action.
On Jul 1, 2013, at 17:15 , Brandon Benvie <bbenvie at mozilla.com> wrote:
So, in the light of modules, are "static" methods necessary?
Static methods that use the |this| value to allow for constructor-side inheritance don't work correctly if simply imported from a module.
See Array.from and Array.of for an example of this in action.
Similarly: @@create (which enables the subtyping of built-ins).
On Jul 1, 2013, at 9:41 AM, Axel Rauschmayer wrote:
On Jul 1, 2013, at 17:15 , Brandon Benvie <bbenvie at mozilla.com> wrote:
So, in the light of modules, are "static" methods necessary?
Static methods that use the |this| value to allow for constructor-side inheritance don't work correctly if simply imported from a module.
See Array.from and Array.of for an example of this in action.
Similarly: @@create (which enables the subtyping of built-ins). ^^^^^^^^ subclassing
Similarly: @@create (which enables the subtyping of built-ins). ^^^^^^^^ subclassing
Curious: is that an important distinction? To me, a (sub)class is the implementation of a (sub)type.
Axel
On Jul 1, 2013, at 10:00 AM, Axel Rauschmayer wrote:
Similarly: @@create (which enables the subtyping of built-ins).
subclassing
Curious: is that an important distinction? To me, a (sub)class is the implementation of a (sub)type.
In a dynamically typed language, a subclass typically isn't required to be a subtype (in most formal senses) of its superclass. In languages like ES subclassing is an implementation technique that supports code sharing among the definitions of similar (a very informal term) objects.
From: Axel Rauschmayer [axel at rauschma.de]
Curious: is that an important distinction? To me, a (sub)class is the implementation of a (sub)type.
This doesn't make much sense in an ES context, where the only types are Undefined, Null, Boolean, String, Number, Symbol, and Object. It's not clear what "subtype" even means.
On 1 July 2013 19:00, Axel Rauschmayer <axel at rauschma.de> wrote:
Similarly: @@create (which enables the subtyping of built-ins). ^^^^^^^^ subclassing
Curious: is that an important distinction? To me, a (sub)class is the implementation of a (sub)type.
Inheritance Is Not Subtyping, see this classic paper:
users.csc.calpoly.edu/~gfisher/work/specl/documentation/related-work/formal-semantics/p125-cook.pdf
Unfortunately, most OO languages still confuse the two.
(JS does not really have subtyping anyway, though.)
Thanks Allen, Domenic, Andreas!
Point taken.
I now remember why I originally started to use the word “subtyping”: I wanted a verb that means deriving a new constructor from an existing constructor C. And I didn’t want to say “extend C”, because that term was already in use in the JS community (Underscore etc.). With ES6, “subclassing” works, because there are classes, but I wouldn’t want to use it for ES5.
Suggestions for a better word are welcome.
Axel
On Mon, Jul 1, 2013 at 5:48 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
Thanks Allen, Domenic, Andreas!
Point taken.
I now remember why I originally started to use the word “subtyping”: I wanted a verb that means deriving a new constructor from an existing constructor C. And I didn’t want to say “extend C”, because that term was already in use in the JS community (Underscore etc.). With ES6, “subclassing” works, because there are classes, but I wouldn’t want to use it for ES5.
Even prior to ES6, if
- B.prototype inherits from A.prototype,
- the B constructor delegates part of the instance state initialization to the A constructor,
- B.prototype.constructor === B, and
- A.prototype.constructor === A then I have been using the term "subclassing". In my experience, no one has been confused by this.
If B is related to A in fewer than all four of these ways, then I describe it without reaching for a shorthand as something weird is going on.
Suggestions for a better word are welcome.
If you're trying to name a relationship with all four of these parts, then I suggest "subclassing". Also, even in ES6, a relationship with all four of these parts should still be called "subclassing" even if it is not expressed with the "class" syntax.
"static" properties of constructors have been used in JS mostly for transport and avoiding pollution of the global object. For example DOMPromise has Promise.any(), a "static method". But if there were modules, any() would probably be better suited as an export: import {Promise, any} from "@promise".
So, in the light of modules, are "static" methods necessary?
Juan
"static" properties of constructors have been used in JS mostly for transport and avoiding pollution of the global object. For example DOMPromise has Promise.any(), a "static method". But if there were modules, any() would probably be better suited as an export: import {Promise, any} from "@promise". So, in the light of modules, are "static" methods necessary? Juan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130701/8f9b4793/attachment.html>