On Jul 20, 2011, at 2:22 AM, Axel Rauschmayer wrote:
> Then lhs and rhs are switched, though. What is the best description of what
> this operator does? “Copy the own properties of an increment to an object”?
> Whatever word(s) are chosen as an infix operator should reflect such a
> description
> From: Brendan Eich
> Date: July 19, 2011 18:59:04 GMT+02:00
> To: Sean Eagan
> Cc: es-discuss
> Subject: Re: An "extend" operator is a natural companion to <|
> "owns" is ambiguous -- could still delegate. Can't use "extends", the
&g
> From: Brendan Eich
> Date: July 19, 2011 21:16:29 GMT+02:00
> To: Luke Hoban
> Cc: "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:
>
>> T
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 i
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 an
On Jul 19, 2011, at 4:33 PM, Allen Wirfs-Brock wrote:
> Actually, I'm trying to explore going the other direction. What would it
> take to allow object literals to use the same syntax as class declarations
> for the things that they have in common.
But why? Even if an object literal is method
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 define the behavior such that no actual mutation of
> [[P
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 adjacen
On Tue, Jul 19, 2011 at 3:45 PM, Brendan Eich 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 declare the
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 docu
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;
>> // decl
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: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 pr
On Jul 19, 2011, at 1:28 PM, Luke Hoban wrote:
> Agreed - my note was just a "most value to the most users the soonest"
> argument. Syntax is clearly important, and many of the proposals can only
> reasonably be offered as syntax. Some of the proposals that can be partly
> delivered as librar
>> 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 browser
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
>>> O
On Jul 19, 2011, at 12:05 PM, Allen Wirfs-Brock wrote:
>> Good point, though it does open the should-constructor-objects-inherit can
>> of worms.
>
> Yes, but it is a can that needs to be emptied.
I agree. Other than "Java didn't have class-side inheritance and I did not miss
it", I haven't he
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
>>
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 s
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
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_drafts&cache=cache&media=harmony:protooperator_alternatives.pdf
>
>
> The first column is by protot
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 s
On Jul 19, 2011, at 10:50 AM, Bob Nystrom wrote:
> On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock
> 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 subclass object yo
>> 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 Tue, 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;
> // decla
Ok, I did a side-by-side comparisons of some alternatives.
Seehttp://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=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:16 AM, Brendan Eich 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 binding (in t
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.
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
av
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 Mon, Jul 18, 2011 at 9:09 PM, Brendan Eich 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() {
>> re
On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock 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 subclass object you might look at the issue quite differently
>
> class Po
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 Jul 18, 2011, at 7:24 PM, Axel Rauschmayer wrote:
>> From: Allen Wirfs-Brock
>> Date: July 18, 2011 19:32:24 GMT+02:00
>> To: es-discuss
>> Subject: An "extend" operator is a natural companion to <|
>
>
> Definitely a nice dual to <|
>
>> proto <| obj
>
>
> What happens if obj is not a
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 Eich wrote:
// replace<| with<>
let B = A<> {...}; // looks like a (prototype) chain link
How so?
I'm talking about visual similarity with an actual physical cha
On Jul 19, 2011, at 7:44 AM, Sean Eagan wrote:
> On Tue, Jul 19, 2011 at 9:39 AM, Sean Eagan 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. Indeed it
On Jul 19, 2011, at 7:39 AM, Sean Eagan wrote:
> On Mon, Jul 18, 2011 at 4:01 PM, Brendan Eich 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 Tue, Jul 19, 2011 at 9:39 AM, Sean Eagan 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
https://mail.mozilla.org/list
On Mon, Jul 18, 2011 at 4:01 PM, Brendan Eich 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 it as "t
> From: Brendan Eich
> Date: July 19, 2011 6:09:17 GMT+02:00
> To: Rick Waldron
> Cc: es-discuss
> Subject: Re: An "extend" operator is a natural companion to <|
>
> This is actually close to a less magical syntax that flips around the
> "Class
> From: Brendan Eich
> Date: July 19, 2011 5:59:16 GMT+02:00
> To: Allen Wirfs-Brock
> Cc: es-discuss
> Subject: Re: An "extend" operator is a natural companion to <|
>
>
> On Jul 18, 2011, at 6:50 PM, Allen Wirfs-Brock wrote:
>
>>> Even in
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 {
> manhattanDist
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 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 producti
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.isN
> From: Bob Nystrom
> Date: July 19, 2011 2:31:48 GMT+02:00
> To: Brendan Eich
> Cc: es-discuss
> Subject: Re: An "extend" operator is a natural companion to <|
To me, the important thing with class literals is to use naming consistently.
If the class is nam
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 COBO
On Jul 18, 2011, at 4:50 PM, Bob Nystrom wrote:
>
>
> On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock
> 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. Java/C# s
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 Ma
On Mon, Jul 18, 2011 at 4:59 PM, Brendan Eich 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
>> primary abstr
On Jul 18, 2011, at 4:50 PM, Bob Nystrom wrote:
> On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock
> 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. Java/C# static m
On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock 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. Java/C# static methods are not
> inherited/over-ridable...of course th
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 cou
On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
> On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock
> 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
On Jul 18, 2011, at 11:26 AM, Dmitry A. Soshnikov wrote:
> On 18.07.2011 21:32, Allen Wirfs-Brock wrote:
>>
>> 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
On Jul 18, 2011, at 1:39 PM, Sean Eagan wrote:
> On Mon, Jul 18, 2011 at 1:44 PM, Allen Wirfs-Brock
> 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 w
On Mon, Jul 18, 2011 at 1:44 PM, Allen Wirfs-Brock
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 each oper
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 <
On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock
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 make a
distinction b
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 <&
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 b
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.
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, LH
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
64 matches
Mail list logo
