My opinion can be summarized as follows: The operator is really useful, we need
it or at least its functionality (alternatively, as a method). I suspect that
the patterns are better supported via class literals that hides the details via
sugaring, but they elegantly illustrate why the operator
From: Brendan Eich bren...@mozilla.com
Date: July 19, 2011 21:16:29 GMT+02:00
To: Luke Hoban lu...@microsoft.com
Cc: es-discuss@mozilla.org es-discuss@mozilla.org
Subject: Re: An extend operator is a natural companion to |
On Jul 19, 2011, at 11:56 AM, Luke Hoban wrote:
The arguments
From: Brendan Eich bren...@mozilla.com
Date: July 19, 2011 18:59:04 GMT+02:00
To: Sean Eagan seaneag...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Subject: Re: An extend operator is a natural companion to |
owns is ambiguous -- could still delegate. Can't use extends, the
direction
From: Brendan Eich bren...@mozilla.com
Date: July 19, 2011 5:59:16 GMT+02:00
To: Allen Wirfs-Brock al...@wirfs-brock.com
Cc: es-discuss es-discuss@mozilla.org
Subject: Re: An extend operator is a natural companion to |
On Jul 18, 2011, at 6:50 PM, Allen Wirfs-Brock wrote:
Even
From: Brendan Eich bren...@mozilla.com
Date: July 19, 2011 6:09:17 GMT+02:00
To: Rick Waldron waldron.r...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Subject: Re: An extend operator is a natural companion to |
This is actually close to a less magical syntax that flips around
On Mon, Jul 18, 2011 at 4:01 PM, Brendan Eich bren...@mozilla.com wrote:
// replace | with
let B = A {...}; // looks like a (prototype) chain link
How so?
I'm talking about visual similarity with an actual physical chain link.
That link is unidirectional. I don't buy it,
I'm thinking of
On Tue, Jul 19, 2011 at 9:39 AM, Sean Eagan seaneag...@gmail.com wrote:
// replace with owns
let b = B owns {
Sorry, that should have just been...
B owns {
...
}
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
On Jul 19, 2011, at 7:39 AM, Sean Eagan wrote:
On Mon, Jul 18, 2011 at 4:01 PM, Brendan Eich bren...@mozilla.com wrote:
// replace | with
let B = A {...}; // looks like a (prototype) chain link
How so?
I'm talking about visual similarity with an actual physical chain link.
Very visual
On Jul 19, 2011, at 7:44 AM, Sean Eagan wrote:
On Tue, Jul 19, 2011 at 9:39 AM, Sean Eagan seaneag...@gmail.com wrote:
// replace with owns
let b = B owns {
Sorry, that should have just been...
B owns {
...
}
B conquers {...}
Half-kidding. The mutating aspect still bothers me.
On 19.07.2011 20:59, Brendan Eich wrote:
On Jul 19, 2011, at 7:39 AM, Sean Eagan wrote:
On Mon, Jul 18, 2011 at 4:01 PM, Brendan Eichbren...@mozilla.com wrote:
// replace| with
let B = A {...}; // looks like a (prototype) chain link
How so?
I'm talking about visual similarity with an
On Jul 18, 2011, at 7:24 PM, Axel Rauschmayer wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
Date: July 18, 2011 19:32:24 GMT+02:00
To: es-discuss es-discuss@mozilla.org
Subject: An extend operator is a natural companion to |
Definitely a nice dual to |
proto | obj
What
On Jul 19, 2011, at 10:06 AM, Dmitry A. Soshnikov wrote:
Object.extend(src, dest)
This is certainly closest to paving the cowpath. Either via a built-in module
exporting 'extend', or as you suggest, directly on Object. The Object.extend
route is a bit harder to analyze, but not fatally so for
On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
But if you were coming from a language where constructors (classes) were
real objects with real methods that could reference this and which were
inherited by subclass object you might look at the issue quite
On Mon, Jul 18, 2011 at 9:09 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 18, 2011, at 9:02 PM, Rick Waldron wrote:
Hey Bob, FWIW...
class Point {
constructor(x, y) {
this.x = x;
this.y = y;
}
zero() {
return new Point(0, 0);
}
unit() {
return new
On Jul 19, 2011, at 10:20 AM, Brendan Eich wrote:
On Jul 19, 2011, at 10:06 AM, Dmitry A. Soshnikov wrote:
Object.extend(src, dest)
Oops, except you have the arguments tranposed (thanks to shaver for pointing
this out to me).
Object.extend(dst, src)
or
import extend from @obj;
On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
This is probably a terrible idea, but in the interest of considering all
options,
Not terrible at all, and thanks for considering more options. I claim that is
what es-discuss is for, so long as you've thought out the pitch and checked to
On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
// new lets you declare members on new instances. these would presumably be
// invoked on the new object before the constructor body is run.
new:
numAttacks = 0;
// declaring an instance property here mainly so you can document it. could
On Tue, Jul 19, 2011 at 11:16 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
(It may be that we should use constructor: or static: instead of class:.)
Those hurt more. I like class, it is shortest and closest to the keyword
that introduces the
Ok, I did a side-by-side comparisons of some alternatives.
Seehttp://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:protooperator_alternatives.pdf
The first column is by prototypal inheritance example using| and from the
first message in
On Tue, Jul 19, 2011 at 11:23 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
// new lets you declare members on new instances. these would presumably
be
// invoked on the new object before the constructor body is run.
new:
numAttacks = 0;
Object.extend(src, dest)
This is certainly closest to paving the cowpath. Either via a built-in module
exporting 'extend', or as you suggest, directly on Object. The Object.extend
route is a bit harder to analyze, but not fatally so for any capable static
analysis framework.
Either way
On Jul 19, 2011, at 10:50 AM, Bob Nystrom wrote:
On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
But if you were coming from a language where constructors (classes) were real
objects with real methods that could reference this and which were inherited
by
On Jul 19, 2011, at 11:37 AM, Bob Nystrom wrote:
Yeah, I don't like things that look like bare assignment either. I know Mark
isn't a fan, but I'd consider:
new:
var numAttacks = 0;
var name;
Or maybe let. I like leading with some keyword.
Those mislead, although var less so in
On Jul 19, 2011, at 11:39 AM, Allen Wirfs-Brock wrote:
Ok, I did a side-by-side comparisons of some alternatives.
Seehttp://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:protooperator_alternatives.pdf
The first column is by prototypal
On Jul 19, 2011, at 11:56 AM, Luke Hoban wrote:
The arguments in favor of a library alternative are:
1) Immediately useful to all JS developers
2) Simple, understandable syntax consistent with existing practice
I agree with all this, but demur here:
From discussions with some Microsoft dev
On Jul 19, 2011, at 11:56 AM, Luke Hoban wrote:
Object.extend(src, dest)
This is certainly closest to paving the cowpath. Either via a built-in
module exporting 'extend', or as you suggest, directly on Object. The
Object.extend route is a bit harder to analyze, but not fatally so for any
On Jul 19, 2011, at 12:10 PM, Brendan Eich wrote:
On Jul 19, 2011, at 11:39 AM, Allen Wirfs-Brock wrote:
The third column uses Object.specialize and Object.extend calls instead of
| and .
Note that Object.create can't be used instead of Object.specialize because I
want the second
On Jul 19, 2011, at 12:17 PM, Allen Wirfs-Brock wrote:
On Jul 19, 2011, at 11:56 AM, Luke Hoban wrote:
Object.extend(src, dest)
This is certainly closest to paving the cowpath. Either via a built-in
module exporting 'extend', or as you suggest, directly on Object. The
Object.extend
From discussions with some Microsoft dev teams, that could be a 3+ year
difference in adoption timeline.
If this is a give me the goods now argument, and the goods can be expressed
via functions, I'm with you.
If this is new syntax takes too long to be usable due to downrev browsers,
On Jul 19, 2011, at 11:16 AM, Brendan Eich wrote:
On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
// private before a section lets you declare private members on that
object.
private new:
health;
Not sure we need 'new' there given lack of private prototype properties in
the
On Jul 19, 2011, at 2:44 PM, Allen Wirfs-Brock wrote:
These were largely topics of another thread which I want to get back to with
some new thoughts. But these issue may have impact of details of the direct
of the design discussion in this thread. I don't think it works to try to
add
On Jul 19, 2011, at 11:23 AM, Brendan Eich wrote:
On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
// new lets you declare members on new instances. these would presumably be
// invoked on the new object before the constructor body is run.
new:
numAttacks = 0;
// declaring an
On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:
The plain name; also looks like a useless expression-statement.
When we talked some people pretty strongly felt that it was very desirable to
be able to explicitly declare the intended per instance properties. In
addition to document
On Tue, Jul 19, 2011 at 3:45 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:
The plain name; also looks like a useless expression-statement.
When we talked some people pretty strongly felt that it was very desirable
to be able to explicitly
On Jul 19, 2011, at 3:45 PM, Brendan Eich wrote:
On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:
Also, why ; instead of , like in object literals
We've been over this before: because methods have braced bodies that should
not require either ; or , to be separate from adjacent
On Jul 19, 2011, at 6:12 PM, Gavin Barraclough wrote:
On Jul 19, 2011, at 12:17 PM, Allen Wirfs-Brock wrote:
One issue is that | conceptually modifies the [[Prototype]] of its RHS. As
an operator (whether special character or keyword based) we can restrict the
RHS to be a literal and
I've recently been experimenting with coding both prototypal and class based
object definitions using the various syntactic forms that are currently on the
table. Something has emerged from that which has surprised me. I have never
been a big fan of the extend method that is provided by a
It would also allow declarative non-integer own properties for arrays,
and arbitrary own properties to regular expressions, numbers,
booleans, and strings, though I can't think of any specific use cases
for those off of the top of my head.
Also, how about | as opposed to , since it is a dual to |
Hawt.
A bit rough in that LHS RHS mutates LHS, whereas LHS | RHS is pure and
produces a new object (which could be optimized to mutate RHS, note well!).
Both | and are operators, to support chaining. Would it be better for to
be pure as | is, and make an assignment operator form, LHS = RHS,
On Jul 18, 2011, at 11:29 AM, Sean Eagan wrote:
It would also allow declarative non-integer own properties for arrays,
and arbitrary own properties to regular expressions, numbers,
booleans, and strings, though I can't think of any specific use cases
for those off of the top of my head.
Le 18/07/2011 19:32, Allen Wirfs-Brock a écrit :
I've recently been experimenting with coding both prototypal and class
based object definitions using the various syntactic forms that are
currently on the table. Something has emerged from that which has
surprised me. I have never been a big
On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote:
Hawt.
A bit rough in that LHS RHS mutates LHS, whereas LHS | RHS is pure and
produces a new object (which could be optimized to mutate RHS, note well!).
Both | and are operators, to support chaining. Would it be better for
to be pure
On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
This is a nice declarative way to describe the per instance state but it
turns out it doesn't generalize very well to multiple levels of inheritance.
This is an important point. I think the reason most OOP languages
On Jul 18, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote:
Hawt.
A bit rough in that LHS RHS mutates LHS, whereas LHS | RHS is pure and
produces a new object (which could be optimized to mutate RHS, note well!).
Both | and are operators,
On Mon, Jul 18, 2011 at 1:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Also, how about | as opposed to , since it is a dual to | adding
own rather than inherited properties?
I'd be a bit concerned about some people getting confused about which
direction of the arrow corresponds to
On Jul 18, 2011, at 1:39 PM, Sean Eagan wrote:
On Mon, Jul 18, 2011 at 1:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Also, how about | as opposed to , since it is a dual to | adding
own rather than inherited properties?
I'd be a bit concerned about some people getting confused
On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
This is a nice declarative way to describe the per instance state but it
turns out it doesn't generalize very well to multiple levels of inheritance.
This
On Jul 18, 2011, at 1:37 PM, Brendan Eich wrote:
On Jul 18, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote:
Hawt.
A bit rough in that LHS RHS mutates LHS, whereas LHS | RHS is pure and
produces a new object (which could be optimized to
On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
2. Familiar from other languages and it works about the same here as it
does in those
Arguably it doesn't. Java/C# static methods are not
On Mon, Jul 18, 2011 at 4:59 PM, Brendan Eich bren...@mozilla.com wrote:
The primary purpose of a class is to define the behavior (methods) of
instances. It is describing an abstraction over all the possible instances.
The behavior of the singleton class object is typically secondary to the
On Jul 18, 2011, at 5:31 PM, Bob Nystrom wrote:
class Point {
constructor(x, y) {
this.x = x;
this.y = y;
}
zero() {
return new Point(0, 0);
}
unit() {
return new Point(1, 1);
}
prototype {
manhattanDistance() {
return Math.abs(this.x) +
On Jul 18, 2011, at 4:50 PM, Bob Nystrom wrote:
On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
2. Familiar from other languages and it works about the same here as it does
in those
Arguably it doesn't.
On Jul 18, 2011, at 4:59 PM, Brendan Eich wrote:
Word on the street, from folks ranging the skill gamut, is that |, and so
on are Perl-ish line noise. We should consider alternatives, even if it means
restricted productions.
As I've said in the past, I'm generally more in the
From: Allen Wirfs-Brock al...@wirfs-brock.com
Date: July 18, 2011 19:32:24 GMT+02:00
To: es-discuss es-discuss@mozilla.org
Subject: An extend operator is a natural companion to |
Definitely a nice dual to |
proto | obj
What happens if obj is not a literal? Then it would make sense to do
From: Bob Nystrom rnyst...@google.com
Date: July 19, 2011 2:31:48 GMT+02:00
To: Brendan Eich bren...@mozilla.com
Cc: es-discuss es-discuss@mozilla.org
Subject: Re: An extend operator is a natural companion to |
To me, the important thing with class literals is to use naming consistently
On Jul 18, 2011, at 6:50 PM, Allen Wirfs-Brock wrote:
Even in Harmony, many of the new methods being adding are static:
Proxy.create(), Proxy.createFunction(), Proxy.isTrapping(),
Object.getPropertyDescriptor(), Object.getPropertyNames(), Object.is(),
Number.isFinite(), Number.isNan()...
On Jul 18, 2011, at 7:00 PM, Allen Wirfs-Brock wrote:
On Jul 18, 2011, at 4:59 PM, Brendan Eich wrote:
Word on the street, from folks ranging the skill gamut, is that |, and
so on are Perl-ish line noise. We should consider alternatives, even if it
means restricted productions.
As
Hey Bob, FWIW...
class Point {
constructor(x, y) {
this.x = x;
this.y = y;
}
zero() {
return new Point(0, 0);
}
unit() {
return new Point(1, 1);
}
prototype {
manhattanDistance() {
return Math.abs(this.x) + Math.abs(this.y);
}
}
}
On Jul 18, 2011, at 9:02 PM, Rick Waldron wrote:
Hey Bob, FWIW...
class Point {
constructor(x, y) {
this.x = x;
this.y = y;
}
zero() {
return new Point(0, 0);
}
unit() {
return new Point(1, 1);
}
prototype {
manhattanDistance() {
59 matches
Mail list logo
