Hi all,
I'm sorry for not having been able to contribute to the internationalization
API earlier. I finally have reviewed the straw man [1], and am pleased to see
that it contains a good subset of internationalization functionality to start
with. Number and date formatting and collation are iss
> 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 Harmony, many of the new methods being adding are "s
> 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
> "ClassElements" (immediate children of the class {...} c
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
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 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 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 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 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 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 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 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 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
av
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 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
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: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
>> 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
> 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
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 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: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: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 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 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: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
>> 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 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
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 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;
>> // decl
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 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: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 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 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 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
38 matches
Mail list logo
