On Sep 30, 2011, at 2:38 AM, Allen Wirfs-Brock wrote:
On Sep 29, 2011, at 4:54 PM, Brendan Eich wrote:
} // optional comma from @awbjs
get x() { return this._x; }
prop: 42,
method() {} // method form @awbjs
};
Waldemar had some objections to comma elision in object literals, they
On Thu, Sep 29, 2011 at 2:53 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
It seems highly desirable that we preserve the existing semantics of arguments
I agree, for backward compatability.
and that:
function foo(...args) {
assert(length.arguments === length.args};
for
Hi,
I've been playing with getters and setters for a little while and
there's one thing really bothering me: You can't store the value in
the object in a hidden way. Here is an example:
http://jsfiddle.net/xavierm02/UzNK3/13/
function Point( x, y ) {
this.x = x;
this.y = y;
}
My implementation sucks and doesn't keep per-instance values. Posting
revision soon.
http://jsfiddle.net/xavierm02/UzNK3/21/
On Fri, Sep 30, 2011 at 3:50 PM, Xavier MONTILLET
xavierm02@gmail.com wrote:
Hi,
I've been playing with getters and setters for a little while and
there's one thing
On Fri, Sep 30, 2011 at 9:50 AM, Xavier MONTILLET
xavierm02@gmail.comwrote:
Hi,
I've been playing with getters and setters for a little while and
there's one thing really bothering me: You can't store the value in
the object in a hidden way. Here is an example:
module name from @name;
let key = name.create();
function MyClass(privateData) {
this[key] = privateData;
}
MyClass.prototype = {
doStuff: function() {
... this[key] ...
}
};
All it does is make the key a special string...
If you get the same string, you can still access the
On Fri, Sep 30, 2011 at 10:14 AM, Xavier MONTILLET
xavierm02@gmail.comwrote:
module name from @name;
let key = name.create();
function MyClass(privateData) {
this[key] = privateData;
}
MyClass.prototype = {
doStuff: function() {
... this[key] ...
}
};
All it does
On Fri, Sep 30, 2011 at 12:26 PM, Xavier MONTILLET
xavierm02@gmail.comwrote:
Maybe it could use more example use cases. What you're proposing above
could also be done by keeping the private value in a closure, but if you
need to hang it off the object this gives you a way to do that
On Thu, Sep 29, 2011 at 6:20 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
On Thu, Sep 29, 2011 at 17:08, Bob Nystrom rnyst...@google.com wrote:
class Monster {
constructor(this.name, this.health) {}
I 3 this. It beats the (public name,
-- Forwarded message --
From: Xavier MONTILLET xavierm02@gmail.com
Date: Fri, Sep 30, 2011 at 7:20 PM
Subject: Re: Proposal: Storage for getters and setters
To: Dean Landolt d...@deanlandolt.com
Alright... So it'll store it with the object as key...
It's really a good idea
On Sep 30, 2011, at 7:12 PM, Bob Nystrom wrote:
We want a syntax for properties on the constructor, so is it worth it to
specifically forbid that notation outside of the class: section?
It's future-proof. Rather do less and get it right than over-reach and regret
the stuff that we got wrong.
On Fri, Sep 30, 2011 at 10:12, Bob Nystrom rnyst...@google.com wrote:
// Constant on class.
const ZERO = new Point(0, 0);
I don't like this. It is too magic and I don't expect people to
remember to use class.ZERO or MyClass.ZERO over this.ZERO.
// Function on class.
class add(a, b) {
On Sep 30, 2011, at 7:56 PM, Brendan Eich wrote:
class Point extends SomeBaseClass {
// Constructor.
constructor(this.x, this.y) {
class.lastPoint = this;
}
class:
// Constant on class.
const ZERO = new Point(0, 0);
// Data property on class.
var lastPoint =
On Fri, Sep 30, 2011 at 10:56 AM, Brendan Eich bren...@mozilla.com wrote:
On Sep 30, 2011, at 7:12 PM, Bob Nystrom wrote:
We want a syntax for properties on the constructor, so is it worth it to
specifically forbid that notation outside of the class: section?
It's future-proof. Rather do
On Sep 30, 2011, at 7:57 PM, Erik Arvidsson wrote:
One of the things I like about the object literal syntax is that it
doesn't seem like things might be in scope. Take this example (with
intentional error):
class Point {
var x = 0;
var y = 0;
distance(other) {
return Math.sqrt(x *
On Sep 30, 2011, at 11:53 AM, Brendan Eich wrote:
On Sep 30, 2011, at 7:57 PM, Erik Arvidsson wrote:
One of the things I like about the object literal syntax is that it
doesn't seem like things might be in scope. Take this example (with
intentional error):
class Point {
var x = 0;
On Sep 30, 2011, at 9:09 PM, Oliver Hunt wrote:
1. Oliver and others do want x and y to be in scope somehow. They can't be
via the |this| parameter object on the scope chain, though. That's dynamic
scope (the prototype is extensible, or *a* prototype, possibly
Object.prototype, is). But
As an aside: love how class is used in Point extends SomeBaseClass, below
(including class.lastPoint).
From: Brendan Eich bren...@mozilla.com
Subject: Re: Sep 27 meeting notes
Date: September 30, 2011 20:53:33 GMT+02:00
To: Erik Arvidsson erik.arvids...@gmail.com
Cc: es-discuss
On Sep 30, 2011, at 12:13 PM, Brendan Eich wrote:
and if it were added i see no reason to restrict it solely constructors.
That said I don't like the syntax at all :D
What, if any, syntax for avoiding repeating each member name three times, do
you prefer?
Personally I don't spend my
Correction (in square brackets):
I consider myself a Java head, but I never liked member variables coming into
the scope of methods. The explicitness and symmetry (when having an argument
whose type is the same as that of this [e.g. in Java equals() methods]) [of
mandatory this] are great.
I wholeheartedly agree with not obsessing about the token count. I’m very
sensitive to context in this regard: in some contexts, I don’t mind or even
welcome additional tokens, in other contexts I hate them.
However, avoiding repeating the same identifier several times seems worth it to
me
On Fri, Sep 30, 2011 at 12:59 PM, Axel Rauschmayer a...@rauschma.de wrote:
I wholeheartedly agree with not obsessing about the token count. I’m very
sensitive to context in this regard: in some contexts, I don’t mind or even
welcome additional tokens, in other contexts I hate them.
However,
I also like it but I am slightly sympathetic with Oliver's argument. I
don't think this is where the issues are at the moment.
I think the main issue at the moment is to get to an agrement whether
a minimal class proposal is acceptable for ES.next.
On Fri, Sep 30, 2011 at 13:07, Bob Nystrom
class Point {
var x = 0;
var y = 0;
distance(other) {
return Math.sqrt(x * other.x + y * other.y);
}
}
it is very tempting to think that var x and var y are in scope.
Would the following analogy with modules help?
Think of 'this' as
- the export object of the constructor method
On 09/30/2011 01:20 AM, Brendan Eich wrote:
On Sep 30, 2011, at 2:38 AM, Waldemar Horwat wrote:
On 09/29/2011 05:08 PM, Bob Nystrom wrote:
On Thu, Sep 29, 2011 at 4:22 PM, Erik
Arvidssonerik.arvids...@gmail.commailto:erik.arvids...@gmail.com wrote:
However, it seems like all the
On Fri, Sep 30, 2011 at 5:11 PM, Claus Reinke claus.rei...@talk21.com wrote:
class Point {
var x = 0;
var y = 0;
distance(other) {
return Math.sqrt(x * other.x + y * other.y);
}
}
it is very tempting to think that var x and var y are in scope.
Would the following analogy with
On Sep 30, 2011, at 2:17 PM, Waldemar Horwat wrote:
On 09/30/2011 01:20 AM, Brendan Eich wrote:
On Sep 30, 2011, at 2:38 AM, Waldemar Horwat wrote:
On 09/29/2011 05:08 PM, Bob Nystrom wrote:
On Thu, Sep 29, 2011 at 4:22 PM, Erik
From: Waldemar Horwat walde...@google.com
Subject: Re: Sep 27 meeting notes
Date: September 30, 2011 23:17:04 GMT+02:00
To: Brendan Eich bren...@mozilla.com
Cc: es-discuss es-discuss@mozilla.org, Erik Arvidsson
erik.arvids...@gmail.com
Without 2, 4, and 5, object initializers are close
below
On Sep 30, 2011, at 2:49 PM, Axel Rauschmayer wrote:
From: Waldemar Horwat walde...@google.com
...
1. Super property references (mainly methods)
2. Super constructor references
3. Subclassing (mainly wiring the prototypes)
4. Defining a class as compactly as possible (with
On Fri, Sep 30, 2011 at 15:27, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 30, 2011, at 9:42 AM, Erik Arvidsson wrote:
On Thu, Sep 29, 2011 at 12:53, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Also, note that I've currently spec'd ES6 so that 'arguments' can be used as
a rest
I pretty much agree with Axel's goals listed here. But I don't think Mark or
Waldemar do. As Erik says, this seems to be the biggest sticking point.
As for IDE's, I'm with Allen: we don't need to bend over backwards. The worst
offender I've seen was the design that involved uninitialized
On Fri, Sep 30, 2011 at 3:17 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I'd argue that my pattern also supports #5 as IDE's can recognize the
pattern. An imperative class definition of all that most Smalltalk
implementations every had and they generally had fine IDEs.
I'm not a
On Fri, Sep 30, 2011 at 3:38 PM, David Herman dher...@mozilla.com wrote:
I disagree. The super patterns are really painful and easy to get wrong in
existing JS, and the benefits of combining a prototype declaration and
constructor declaration in a single form shouldn't be dismissed. It's
On Sep 30, 2011, at 3:40 PM, Bob Nystrom wrote:
On Fri, Sep 30, 2011 at 3:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'd argue that my pattern also supports #5 as IDE's can recognize the
pattern. An imperative class definition of all that most Smalltalk
implementations
On Sep 30, 2011, at 9:39 PM, Oliver Hunt wrote:
On Sep 30, 2011, at 12:13 PM, Brendan Eich wrote:
and if it were added i see no reason to restrict it solely constructors.
That said I don't like the syntax at all :D
What, if any, syntax for avoiding repeating each member name three times,
On Sep 30, 2011, at 9:51 PM, Bob Nystrom wrote:
On Fri, Sep 30, 2011 at 11:53 AM, Brendan Eich bren...@mozilla.com wrote:
1. Oliver and others do want x and y to be in scope somehow. They can't be
via the |this| parameter object on the scope chain, though. That's dynamic
scope (the
On Sep 30, 2011, at 11:17 PM, Waldemar Horwat wrote:
2, 4, and 5 are the most important new features, and there isn't enough
value in classes to add them without those.
This seems like a fundamental conflict with classes as sugar unless we
take the Object.defineProperty semantics as the
That isn't true of most IDEs today that are just working on the program text
itself. With today's editors, the textual format matters. (We might rightly
lament that fact, but it does seem to be the field we've got to play on
right now.)
Some might argue whether this is a step forward or
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
That's what makes this into a dead end. Worse, by claiming the class syntax
you'd be precluding finding a different way that works in the future.
Waldemar
[cc-ing es-discuss]
On Oct 1, 2011, at 1:59 , Juan Ignacio Dopazo wrote:
On Fri, Sep 30, 2011 at 6:49 PM, Axel Rauschmayer a...@rauschma.de wrote:
Wasn’t it David Herman a while ago who listed a minimal feature list? For me
it would be:
1. Super property references (mainly methods)
2.
On Fri, Sep 30, 2011 at 4:57 PM, Waldemar Horwat walde...@google.comwrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
That's what makes this into a dead end. Worse, by claiming the class
syntax you'd be precluding finding a
On Oct 1, 2011, at 1:57 AM, Waldemar Horwat wrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
That's what makes this into a dead end. Worse, by claiming the class syntax
you'd be precluding finding a different way that works
On Oct 1, 2011, at 2:07 AM, Brendan Eich wrote:
On Oct 1, 2011, at 1:57 AM, Waldemar Horwat wrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
That's what makes this into a dead end. Worse, by claiming the class
syntax
On Oct 1, 2011, at 2:16 , Juan Ignacio Dopazo wrote:
1. Don't forget super getters/setters. Those are helpful.
Not sure how often they would be used and whether they need to be part of a
minimal feature set.
Isn't it just a matter of referring to the property with super?
class Pirate
On Oct 1, 2011, at 3:34 AM, Waldemar Horwat wrote:
On 09/30/2011 05:07 PM, Brendan Eich wrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
We can add these later ...
Those two statements you made are in direct contradiction.
I'd argue that my pattern also supports #5 as IDE's can recognize the
pattern. An imperative class definition of all that most Smalltalk
implementations every had and they generally had fine IDEs.
From what I remember from my Smalltalk days (literally – a 14 day project at
school ;-),
One language feature from JavaScript that I miss are enums. Would it make sense
to have something similar for ECMAScript, e.g. via Lisp-style/Smalltalk-style
symbols plus type inference? If yes, has this been discussed already? I feel
strange when I simulate symbols with strings.
--
Dr. Axel
On Oct 1, 2011, at 4:13 AM, Axel Rauschmayer wrote:
One language feature from JavaScript that I miss are enums. Would it make
sense to have something similar for ECMAScript, e.g. via
Lisp-style/Smalltalk-style symbols plus type inference? If yes, has this been
discussed already? I feel
On 09/30/2011 06:51 PM, Brendan Eich wrote:
On Oct 1, 2011, at 3:34 AM, Waldemar Horwat wrote:
On 09/30/2011 05:07 PM, Brendan Eich wrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
We can add these later ...
Those two
On Fri, Sep 30, 2011 at 10:13 PM, Axel Rauschmayer a...@rauschma.de wrote:
One language feature from JavaScript that I miss are enums. Would it make
sense to have something similar for ECMAScript, e.g. via
Lisp-style/Smalltalk-style symbols plus type inference? If yes, has this
been discussed
On Fri, Sep 30, 2011 at 5:47 PM, Axel Rauschmayer a...@rauschma.de wrote:
Isn't it just a matter of referring to the property with super?
class Pirate {
get name() {
return Captn' + super.name;
}
}
just trying to understand: how is super different from __proto__?
jjb
On Oct 1, 2011, at 4:23 AM, Waldemar Horwat wrote:
On 09/30/2011 06:51 PM, Brendan Eich wrote:
On Oct 1, 2011, at 3:34 AM, Waldemar Horwat wrote:
On 09/30/2011 05:07 PM, Brendan Eich wrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that
On Oct 1, 2011, at 5:24 AM, Brendan Eich wrote:
On Oct 1, 2011, at 4:23 AM, Waldemar Horwat wrote:
There are lots of ways to do classes that satisfy all of 2-5. However, it
doesn't matter if those exist if those solutions are not acceptable to the
group.
I know, I was ok with a read
Imagine
class Foo {
function name() {
return foo
}
}
class Bar : Foo { // s/:/extends or whatever
function name() {
super.name();
}
}
class Wibble : Bar {
function name() {
super.name();
}
}
the call to super.name() essentially desugars to:
On Fri, Sep 30, 2011 at 9:01 PM, Oliver Hunt oli...@apple.com wrote:
Imagine
class Foo {
function name() {
return foo
}
}
class Bar : Foo { // s/:/extends or whatever
function name() {
super.name();
}
}
class Wibble : Bar {
function name() {
55 matches
Mail list logo
