Recently Claus Reinke proposed some alternative that I think feels is
so much more natural and simpler than <| or beget:
..
.. re-interpretation deleted ..
Ahem;-) Glad to see my proposal noticed, but what I really
suggested, in
motivating <| as structure representation, not operator
https:
On Nov 22, 2011, at 10:54 AM, Bob Nystrom wrote:
>
> On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich wrote:
>
> Nothing there about arrays or regular expressions, and the function examples
> do *not* show anything like
>
> superFun <| function (...) {...}
>
> Instead of Ahem'ing, could you
2011/11/22 Bob Nystrom
>
> On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich wrote:
>
>>
>> Nothing there about arrays or regular expressions, and the function
>> examples do *not* show anything like
>>
>> superFun <| function (...) {...}
>>
>> Instead of Ahem'ing, could you cite what you claim is
On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich wrote:
>
> Nothing there about arrays or regular expressions, and the function
> examples do *not* show anything like
>
> superFun <| function (...) {...}
>
> Instead of Ahem'ing, could you cite what you claim is a prior proposal
> with specifics sh
On Nov 22, 2011, at 9:48 AM, Claus Reinke wrote:
>>> Recently Claus Reinke proposed some alternative that I think feels is so
>>> much more natural and simpler than <| or beget:
>>> ..
>>> .. re-interpretation deleted ..
>
> Ahem;-) Glad to see my proposal noticed, but what I really
> suggested,
Recently Claus Reinke proposed some alternative that I think feels is so
much more natural and simpler than <| or beget:
..
.. re-interpretation deleted ..
Ahem;-) Glad to see my proposal noticed, but what I really
suggested, in
motivating <| as structure representation, not operator
htt
On 22.11.2011 5:55, Irakli Gozalishvili wrote:
Recently Claus Reinke proposed some alternative that I think feels is
so much more natural and simpler than <| or beget:
Yes, it was proposed long time ago:
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014391.html
let foo = {x: 10};
On Nov 21, 2011, at 5:55 PM, Irakli Gozalishvili wrote:
> Recently Claus Reinke proposed some alternative that I think feels is so much
> more natural and simpler than <| or beget:
>
> Instead of this:
>
> foo <| { bar: 'bar' }
>
> prototype can be a special property:
>
> { prototype: foo, ba
Recently Claus Reinke proposed some alternative that I think feels is so much
more natural and simpler than <| or beget:
Instead of this:
foo <| { bar: 'bar' }
prototype can be a special property:
{ prototype: foo, bar: 'bar' }
simple and easy, of course it can have a different name from `p
On Nov 19, 2011, at 11:38 AM, Dean Landolt wrote:
>
>
> On Sat, Nov 19, 2011 at 1:57 PM, Allen Wirfs-Brock
> wrote:
>
> On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
>
> >
> >
> > but given the overall disapproval of the exact syntax of the <| operator, I
> > think its at least a li
On Sat, Nov 19, 2011 at 11:07 AM, Allen Wirfs-Brock
wrote:
>
> On Nov 17, 2011, at 2:05 PM, David Herman wrote:
>
>> On Nov 17, 2011, at 10:17 AM, Jason Orendorff wrote:
>>
>>> I'm with Allen. If ES classes can contain any initialization code, I
>>> think it should run in program order, interleave
On Sat, Nov 19, 2011 at 1:57 PM, Allen Wirfs-Brock wrote:
>
> On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
>
> >
> >
> > but given the overall disapproval of the exact syntax of the <|
> operator, I think its at least a little more obvious what is going on.
> >
>
> Sorry to be coming late
On Nov 17, 2011, at 2:05 PM, David Herman wrote:
> On Nov 17, 2011, at 10:17 AM, Jason Orendorff wrote:
>
>> I'm with Allen. If ES classes can contain any initialization code, I
>> think it should run in program order, interleaved with top-level
>> statements. Anything else is just confusing.
>
On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
>
>
> but given the overall disapproval of the exact syntax of the <| operator, I
> think its at least a little more obvious what is going on.
>
Sorry to be coming late to this thread.
I think the above statement is a false characteri
On Nov 17, 2011, at 10:17 AM, Jason Orendorff wrote:
> I'm with Allen. If ES classes can contain any initialization code, I
> think it should run in program order, interleaved with top-level
> statements. Anything else is just confusing.
This is a great point, which I'd overlooked (not sure if Al
>
> It is also something that my proposed version of the class operator could
> do, because it always creates a function, and could desugar to the same
> semantics as the current function style.
>
>
> This may seem like a nit-pick, but I think it's not: any variant that sits
> at statement context
On Nov 17, 2011, at 1:34 PM, Russell Leggett wrote:
> On Thu, Nov 17, 2011 at 3:06 PM, David Flanagan wrote:
> On 11/16/11 11:45 AM, Erik Arvidsson wrote:
>>
>> Sorry for being too brief. Today the following works.
>>
>> f();
>> ...
>> function f() { ... }
>>
>> but the following does not:
>>
On Thu, Nov 17, 2011 at 3:06 PM, David Flanagan wrote:
> On 11/16/11 11:45 AM, Erik Arvidsson wrote:
>
> Sorry for being too brief. Today the following works.
>
> f();
> ...
> function f() { ... }
>
> but the following does not:
>
> f();
> ...
> let f = function f() {};
>
> I think it is importan
On Nov 17, 2011, at 10:17 AM, Jason Orendorff wrote:
> On Thu, Nov 17, 2011 at 10:40 AM, David Herman wrote:
>> This isn't about scope, it's about at what point they're initialized. If you
>> write:
>>
>>let x = new C();
>>let C = class /* whatever */;
>>
>> you won't get a scope error
On 11/16/11 11:45 AM, Erik Arvidsson wrote:
Sorry for being too brief. Today the following works.
f();
...
function f() { ... }
but the following does not:
f();
...
let f = function f() {};
I think it is important that we keep the forward reference behavior
with classes. This requires a decla
On Thu, Nov 17, 2011 at 10:40 AM, David Herman wrote:
> This isn't about scope, it's about at what point they're initialized. If you
> write:
>
> let x = new C();
> let C = class /* whatever */;
>
> you won't get a scope error but a runtime initialization error. Whereas if
> you write:
>
>
On Nov 17, 2011, at 8:00 AM, Jason Orendorff wrote:
> On Wed, Nov 16, 2011 at 1:12 PM, Erik Arvidsson
> wrote:
>> One thing that all of these discussions are missing is the hoisting
>> property of function and any possible future classes. If we use "let
>> Point = ..." we lose all hoisting and th
On Wed, Nov 16, 2011 at 1:12 PM, Erik Arvidsson
wrote:
> One thing that all of these discussions are missing is the hoisting
> property of function and any possible future classes. If we use "let
> Point = ..." we lose all hoisting and the order of your declarations
> starts to matter and we will
The biggest advantage to beget is that it has the opportunity to become The
Prototype Word. "inherit" has a lot of people associating it with classical
OO programming. As nice as inherit sounds, it might be good to drop that
baggage.
-Greg
On Wed, Nov 16, 2011 at 2:31 PM, Rick Waldron wrote:
> A
On Nov 16, 2011, at 9:31 PM, David Herman wrote:
> On Nov 16, 2011, at 12:11 PM, Dmitry Soshnikov wrote:
>
>> Yes, I understand, but it doesn't answer the question -- why do we need
>> _additional_ keyword
>
> Infix operators can be conditional keywords. That's the current plan for is,
> IINM.
On Nov 16, 2011, at 12:11 PM, Dmitry Soshnikov wrote:
> Yes, I understand, but it doesn't answer the question -- why do we need
> _additional_ keyword
Infix operators can be conditional keywords. That's the current plan for is,
IINM.
Dave
___
es-dis
On Nov 16, 2011, at 11:12 AM, Erik Arvidsson wrote:
> One thing that all of these discussions are missing is the hoisting
> property of function and any possible future classes. If we use "let
> Point = ..." we lose all hoisting and the order of your declarations
> starts to matter and we will end
On Nov 16, 2011, at 8:19 AM, Russell Leggett wrote:
> On Wed, Nov 16, 2011 at 11:07 AM, Jake Verbaten wrote:
> It's simply that
>
> var x = someProto beget { ... }
>
> reads nicer then
>
> var x = someProto extends { ... }
>
> I'd prefer to have readability on the non class related operator
On Wed, Nov 16, 2011 at 3:11 PM, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:
> **
> On 16.11.2011 23:53, Rick Waldron wrote:
>
>
>
> On Wed, Nov 16, 2011 at 2:34 PM, Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>> But why do we need new keyword?
>>
>
> The discussion origin
On 16.11.2011 23:53, Rick Waldron wrote:
On Wed, Nov 16, 2011 at 2:34 PM, Dmitry Soshnikov
mailto:dmitry.soshni...@gmail.com>> wrote:
But why do we need new keyword?
The discussion originated around how ugly <| is; an infix operator
keyword is easier to introduce into the language the
On Wed, Nov 16, 2011 at 2:34 PM, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:
> But why do we need new keyword?
>
The discussion originated around how ugly <| is; an infix operator keyword
is easier to introduce into the language then an infix operator made of
symbols
>
> Actually, I
On 16 November 2011 20:45, Erik Arvidsson wrote:
> Sorry for being too brief. Today the following works.
>
> f();
> ...
> function f() { ... }
>
> but the following does not:
>
> f();
> ...
> let f = function f() {};
>
> I think it is important that we keep the forward reference behavior
> with cl
On Wed, Nov 16, 2011 at 11:29, Andreas Rossberg wrote:
> On 16 November 2011 20:12, Erik Arvidsson wrote:
>> One thing that all of these discussions are missing is the hoisting
>> property of function and any possible future classes. If we use "let
>> Point = ..." we lose all hoisting and the ord
But why do we need new keyword?
Actually, I can accept a new keyword in case if reasons will really be
serious. But in this case -- `extends' may fit quite nice.
P.S.: In general, it's just funny picture. Somehow ES4 made nice classes
with nice syntax. Why (Why Y NO?) now we invent some scary
As stated previously[1], my support for "begets" as pure win is unwavering.
Rick
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-October/017758.html
On Wed, Nov 16, 2011 at 2:16 PM, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:
> On 16.11.2011 23:12, Erik Arvidsson wrote:
>
>
On 16 November 2011 20:12, Erik Arvidsson wrote:
> One thing that all of these discussions are missing is the hoisting
> property of function and any possible future classes. If we use "let
> Point = ..." we lose all hoisting and the order of your declarations
> starts to matter and we will end up
On 16.11.2011 23:19, Quildreen Motta wrote:
But with `var', only the declaration is hoisted, the actual assignment
is not. Such that:
var point3d = extends point { z: 1 }
var point = { x: 1, y : 1 }
Right, but I used declarative form, w/o assignment:
var point3d extends point { z: 1}
OTOH
But with `var', only the declaration is hoisted, the actual assignment is
not. Such that:
var point3d = extends point { z: 1 }
var point = { x: 1, y : 1 }
Would still fail, as far as I know, whereas:
class point3d extends point { z: 1 }
class point { x: 1, y: 1 }
Should work, if class is hoiste
On 16.11.2011 23:12, Erik Arvidsson wrote:
One thing that all of these discussions are missing is the hoisting
property of function and any possible future classes. If we use "let
Point = ..." we lose all hoisting and the order of your declarations
starts to matter and we will end up in the C mes
One thing that all of these discussions are missing is the hoisting
property of function and any possible future classes. If we use "let
Point = ..." we lose all hoisting and the order of your declarations
starts to matter and we will end up in the C mess where forward
references do not work.
--
On Wed, Nov 16, 2011 at 11:07 AM, Jake Verbaten wrote:
> It's simply that
>
> var x = someProto beget { ... }
>
> reads nicer then
>
> var x = someProto extends { ... }
>
> I'd prefer to have readability on the non class related operator then the
> class related operator
>
I was actually suggest
It's simply that
var x = someProto beget { ... }
reads nicer then
var x = someProto extends { ... }
I'd prefer to have readability on the non class related operator then the
class related operator
On Wed, Nov 16, 2011 at 3:45 PM, Russell Leggett
wrote:
> On Wed, Nov 16, 2011 at 10:31 AM, Jake
On Wed, Nov 16, 2011 at 10:31 AM, Jake Verbaten wrote:
> I think there was a naming discussion in another thread.
>
> Popular alternatives seemed to be "beget" and "proto"/"protos". I still
> seem to like "beget"
>
The reason I suggest it is *entirely* based on its relation to the
potential clas
I think there was a naming discussion in another thread.
Popular alternatives seemed to be "beget" and "proto"/"protos". I still
seem to like "beget"
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
"How is it different from Object.create(...)? Actually yes, it's just an
alternative and in contrast with O.create, I think here we may use not
descriptors but directly values."
The importance of this difference can't be understated. Object.create's
verbosity makes it a poor idiom for everyday pro
On Wed, Nov 16, 2011 at 4:42 AM, Dmitry Soshnikov <
dmitry.soshni...@gmail.com> wrote:
> On 16.11.2011 10:27, Russell Leggett wrote:
>
> Given the recent conversation about class as operator and its likely
> composition with <|, I propose turning the syntax:
>
> *MemberExpression* <| *ProtoL
On 16.11.2011 10:27, Russell Leggett wrote:
Given the recent conversation about class as operator and its likely
composition with <|, I propose turning the syntax:
/MemberExpression/ <| /ProtoLiteral/
into
extends /MemberExpression ProtoLiteral/
In the common case of using the class operato
Given the recent conversation about class as operator and its likely
composition with <|, I propose turning the syntax:
*MemberExpression* <| *ProtoLiteral*
into
extends *MemberExpression ProtoLiteral*
In the common case of using the class operator, it would read much more
naturally:
48 matches
Mail list logo
