I wrote the following:
>>
>>> From: Axel Rauschmayer
>>> Date: June 13, 2011 10:55:56 GMT+02:00
>>> To: Allen Wirfs-Brock , es-discuss
>>>
>>> Subject: Re: Classes: suggestions for improvement
>>>
>>>> The correspondence is no
On Jun 14, 2011, at 8:51 PM, Breton Slivka wrote:
> Perhaps I am overlooking something obvious, but is there something
> wrong with calling a constructor function `constructor`, rather than
> class or proto or prototype?
Yes, we've been over this in various places, probably need it recorded on th
Perhaps I am overlooking something obvious, but is there something
wrong with calling a constructor function `constructor`, rather than
class or proto or prototype?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-di
On Jun 13, 2011, at 10:07 PM, Peter Michaux wrote:
> On Mon, Jun 13, 2011 at 12:31 PM, Brendan Eich wrote:
>
>> The language to emulate is Smalltalk, though.
>
> +1 to that; however, the ES class proposal is not very similar to
> Smalltalk classes. Others are far more qualified to enumerate the
On Jun 14, 2011, at 3:00 PM, Axel Rauschmayer wrote:
> But in general: point taken. I do like the idea to use “factory”, but “class”
> might be close enough to people’s expectations that it works. What I find
> complicated is that what would be a class in, say, Python, is two constructs
> in J
> JS uses "prototype" to mean two distinct things:
> 1) the object associated with a constructor function that's used as the
> prototypical instance of objects created by that constructor and
> 2) the object an object inherits from. (Self uses "parent" for the latter,
> which makes things less co
On Jun 14, 2011, at 1:34 PM, felix wrote:
> On Tue, Jun 14, 2011 at 13:21, Bob Nystrom wrote:
>> On Tue, Jun 14, 2011 at 1:05 PM, felix wrote:
>>>
>>> How about using "prototype" or "proto" as the keyword instead of "class"?
>>>
>>> It's a declaration of a prototypical object used to generate
On Tue, Jun 14, 2011 at 1:57 PM, felix wrote:
> On Tue, Jun 14, 2011 at 13:46, Bob Nystrom wrote:
> > On Tue, Jun 14, 2011 at 1:34 PM, felix wrote:
> >>> Hm, by that argument "class" isn't a particularly good term either,
> >> since the thing created is not a class, it's a thing that generates
On Tue, Jun 14, 2011 at 13:46, Bob Nystrom wrote:
> On Tue, Jun 14, 2011 at 1:34 PM, felix wrote:
>>
>> > I think that's been considered before. My complaint with it is that
>> > Point
>> > isn't a prototype. It's a constructor function whose .prototype property
>> > is
>> > the prototype. In oth
On Tue, Jun 14, 2011 at 1:34 PM, felix wrote:
> > I think that's been considered before. My complaint with it is that Point
> > isn't a prototype. It's a constructor function whose .prototype property
> is
> > the prototype. In other words, the object bound to the name Point isn't
> the
> > proto
On Tue, Jun 14, 2011 at 13:21, Bob Nystrom wrote:
> On Tue, Jun 14, 2011 at 1:05 PM, felix wrote:
>>
>> How about using "prototype" or "proto" as the keyword instead of "class"?
>>
>> It's a declaration of a prototypical object used to generate other
>> objects.
>>
>> "prototype" is already a fam
On Tue, Jun 14, 2011 at 1:05 PM, felix wrote:
> How about using "prototype" or "proto" as the keyword instead of "class"?
>
> It's a declaration of a prototypical object used to generate other objects.
>
> "prototype" is already a familiar word to JS programmers; this is just
> extending its use
How about using "prototype" or "proto" as the keyword instead of "class"?
It's a declaration of a prototypical object used to generate other objects.
"prototype" is already a familiar word to JS programmers; this is just
extending its use into a new but similar context.
"prototype" has a looser,
On Mon, Jun 13, 2011 at 12:31 PM, Brendan Eich wrote:
> The language to emulate is Smalltalk, though.
+1 to that; however, the ES class proposal is not very similar to
Smalltalk classes. Others are far more qualified to enumerate the
differences than I am.
For example, how can we do desugared c
On Jun 13, 2011, at 12:26 PM, Brendan Eich wrote:
> +1. Very nicely put.
>
> /be
One more thought:
>>
>>
>> In part I think class is the wrong word, as cowboyd tweeted (see below).
>>
>> Agreed. "class" isn't ideal, but it's probably the best we have. It carries
>> a lot of baggage, some o
+1. Very nicely put.
/be
On Jun 13, 2011, at 11:51 AM, Bob Nystrom wrote:
> On Sun, Jun 12, 2011 at 2:38 PM, Brendan Eich wrote:
> Something about classes in JS makes me sad, an emotional effect I can't
> explain fully.
>
>
>
> I'm one of the biggest fans of this class proposal, and I feel
On Sun, Jun 12, 2011 at 2:38 PM, Brendan Eich wrote:
> Something about classes in JS makes me sad, an emotional effect I can't
> explain fully.
>
I'm one of the biggest fans of this class proposal, and I feel a twinge of
that sadness too. I look at it as JS taking a step away from Scheme and
t
On Jun 13, 2011, at 10:33 AM, Kam kasravi wrote:
> On Jun 12, 2011, at 10:49 PM, Brendan Eich wrote:
>
>> On Jun 12, 2011, at 8:46 PM, Axel Rauschmayer wrote:
>>
>>> I’ve only got one use case for this, but “class methods” would also work
>>> better if they could be attached to the prototype (
On Jun 12, 2011, at 10:49 PM, Brendan Eich wrote:
> On Jun 12, 2011, at 8:46 PM, Axel Rauschmayer wrote:
>
>> I’ve only got one use case for this, but “class methods” would also work
>> better if they could be attached to the prototype (and subject to
>> inheritance) instead of the construct
On Jun 13, 2011, at 8:41 AM, Juan Ignacio Dopazo wrote:
> On Sun, Jun 12, 2011 at 10:17 PM, Brendan Eich wrote:
>
> I'm not sure classes should grow to have private class or prototype variables
> in ES.next. Mark stripped things down to help get classes in. The one reason
> I come back to the
On Mon, Jun 13, 2011 at 12:01 PM, Kam Kasravi wrote:
>
> On Jun 13, 2011, at 1:55 AM, Axel Rauschmayer wrote:
>
> Indeed a number of frameworks use 'initialize' for their 'ctor'. I imagine
> this has been
> heavily discussed within TC39, but perhaps some of the rational has not
> made es-discuss
On Jun 13, 2011, at 1:55 AM, Axel Rauschmayer wrote:
> Excellent points, thanks! Wasn’t aware that Smalltalk did duck typing, but it
> must make things much more generic.
>
> Note: IIRC, Self calls its prototypical instances “prototypes”. What
> JavaScript calls a prototype (both the relatio
Excellent points, thanks! Wasn’t aware that Smalltalk did duck typing, but it
must make things much more generic.
Note: IIRC, Self calls its prototypical instances “prototypes”. What JavaScript
calls a prototype (both the relation and the objects forming the right-hand
sides of such a relation)
On Jun 12, 2011, at 8:46 PM, Axel Rauschmayer wrote:
> I’ve only got one use case for this, but “class methods” would also work
> better if they could be attached to the prototype (and subject to
> inheritance) instead of the constructor.
We had a thread about this, because Ruby and CoffeeScrip
On Jun 12, 2011, at 8:46 PM, Axel Rauschmayer wrote:
>> So, there is pretty much a directly correspondence between a self copy
>> method and a JavaScript constructor function. However, there is definitely
>> a difference of emphasis seen here. In self, it is the prototype object
>> that is t
> So, there is pretty much a directly correspondence between a self copy method
> and a JavaScript constructor function. However, there is definitely a
> difference of emphasis seen here. In self, it is the prototype object that
> is the focus of attention. In traditional JavaScript it is the
On Jun 12, 2011, at 4:13 PM, Axel Rauschmayer wrote:
> Two observations:
>
> - Object.create() seems to have started something truly prototypal in
> JavaScript that never quite got finished. If there was a way to bring more
> Self to JavaScript (instead of more Java, Python, or Ruby) when it c
On Jun 12, 2011, at 4:54 PM, Juan Ignacio Dopazo wrote:
> If I understand correctly the reason for needing private(this).x is because
> the private names proposal allows having a private name with the same name as
> a common property.
Whether private in class uses private name objects or some o
On Sun, Jun 12, 2011 at 6:38 PM, Brendan Eich wrote:
> On Jun 12, 2011, at 2:22 PM, Axel Rauschmayer wrote:
>
> (1) The syntax for private properties still is a bit clumsy, and @ feels
> like wasting a nice symbol, how about using private.foo instead of
> private(this).foo?
>
>
> No, you need pri
On Sun, Jun 12, 2011 at 2:38 PM, Brendan Eich wrote:
>
> On Jun 12, 2011, at 2:22 PM, Axel Rauschmayer wrote:
> > Does anybody know what Brendan meant in this txjs talk with “Classes made
> > it (Yay, I think? Why am I sad?)”? Is he ambivalent about the proposal? Is
> > there anything he doesn’t
>> Something about classes in JS makes me sad, an emotional effect I can't
>> explain fully. In part I fear the "lint brush" aspect I mentioned in the
>> thread Irakli just followed up: class syntax will grow lots of hair over
>> time. In part I think class is the wrong word, as cowboyd tweeted
On Jun 12, 2011, at 3:49 PM, Axel Rauschmayer wrote:
>>> and the "static" keyword for defining class properties are welcome
>>> additions.
>>
>> Why "static" is the wrong word: there is nothing compile-time about the
>> class properties. Classes are expressible (anonymous, even), as well as
>>
On Jun 12, 2011, at 3:43 PM, Axel Rauschmayer wrote:
>>> (1) The syntax for private properties still is a bit clumsy, and @ feels
>>> like wasting a nice symbol, how about using private.foo instead of
>>> private(this).foo?
>>
>> No, you need private(other).foo or shorter for things like
>>
>>
>> and the "static" keyword for defining class properties are welcome additions.
>
> Why "static" is the wrong word: there is nothing compile-time about the class
> properties. Classes are expressible (anonymous, even), as well as declarable
> in nested (generative) ways.
>
> Using "class" does
>> (1) The syntax for private properties still is a bit clumsy, and @ feels
>> like wasting a nice symbol, how about using private.foo instead of
>> private(this).foo?
>
> No, you need private(other).foo or shorter for things like
>
> class Point {
>constructor(x, y) {
> private x = x
On Jun 12, 2011, at 2:38 PM, Brendan Eich wrote:
> Something about classes in JS makes me sad, an emotional effect I can't
> explain fully. In part I fear the "lint brush" aspect I mentioned in the
> thread Irakli just followed up: class syntax will grow lots of hair over
> time. In part I thin
On Jun 12, 2011, at 2:22 PM, Axel Rauschmayer wrote:
> I really like the proposal: it is very lightweight syntactic sugar. For
> example, it is not that radically different from Resig’s Simple Inheritance
> (whose "look" I like).
There is good in the proposal, don't get me wrong. I worked on it
On Jun 12, 2011, at 2:38 PM, Brendan Eich wrote:
>> (3) Is "static const" possible?
>
> Yes, see
Oops, accidentally cut "the grammar".
ClassPropertyDefinition :
static ExportableDefinition
ExportableDefinition :
Declaration
and Declaration : const Pattern.
/be
__
On Jun 12, 2011, at 2:22 PM, Axel Rauschmayer wrote:
> (1) The syntax for private properties still is a bit clumsy, and @ feels like
> wasting a nice symbol, how about using private.foo instead of
> private(this).foo?
No, you need private(other).foo or shorter for things like
class Point {
I really like the proposal: it is very lightweight syntactic sugar. For
example, it is not that radically different from Resig’s Simple Inheritance
(whose "look" I like). The "super" keyword for calling overridden methods and
chaining super-constructors and the "static" keyword for defining clas
40 matches
Mail list logo
