Ok I wrote up another gist
https://gist.github.com/7e649e8c33d412e90178
that no longer refers to any non-existing functions like `Function.create` and
addresses `super` sugar issue using `base` function (In a similar way as in
Dmitry's link).
Also, implementation uses deprecated `caller`,
Hi,
Is there anything else (other than starting this thread) I can do to make
committee consider `Function.prototype.extend` as an alternative to a proposed
class sugar ?
Thanks
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France
On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote:
Hi,
Is there anything else (other than starting this thread) I can do to make
committee consider `Function.prototype.extend` as an alternative to a
proposed class sugar ?
Could you show Function.prototype.extend again, and say
On 13.06.2011 1:18, Brendan Eich wrote:
On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote:
Hi,
Is there anything else (other than starting this thread) I can do to
make committee consider `Function.prototype.extend` as an alternative
to a proposed class sugar ?
Could you show
On 13.06.2011 1:43, Dmitry A. Soshnikov wrote:
On 13.06.2011 1:18, Brendan Eich wrote:
On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote:
Hi,
Is there anything else (other than starting this thread) I can do to
make committee consider `Function.prototype.extend` as an
alternative to a
On Sunday, 2011-06-12 at 23:18 , Brendan Eich wrote:
On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote:
Hi,
Is there anything else (other than starting this thread) I can do to make
committee consider `Function.prototype.extend` as an alternative to a
proposed class sugar ?
On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote:
Here is gist I wrote before:
https://gist.github.com/986487#file_implementation.js
What Function.create are you using there?
Is there a missing return statement in function extend?
and say how it solves the super-construct and
On Monday, 2011-06-13 at 24:03 , Brendan Eich wrote:
On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote:
Here is gist I wrote before:
https://gist.github.com/986487#file_implementation.js
What Function.create are you using there?
Is there a missing return statement
On Monday, June 13, 2011, Brendan Eich bren...@mozilla.com wrote:
On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote:On Monday, 2011-06-13
at 24:03 , Brendan Eich wrote:
On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote:
Here is gist I wrote
On Jun 12, 2011, at 3:38 PM, Irakli Gozalishvili wrote:
On Monday, June 13, 2011, Brendan Eich bren...@mozilla.com wrote:
On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote:On Monday, 2011-06-13
at 24:03 , Brendan Eich wrote:
On Jun 12, 2011, at 2:52 PM, Irakli
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new functionality added or
shortens most commonly used constructs like functions (were no other
option is available). In case of this
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new functionality added or shortens
most commonly used
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
extensions, which is probably worth if new
On May 23, 2011, at 8:31 AM, Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
1. More syntax means larger language surface, which adds complexity more
things to remember / learn. More things to consider in ES.next.next
It's true, although not everyone learns it
On Monday, 2011-05-23 at 17:31 , Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require
On Monday, 2011-05-23 at 18:14 , Isaac Schlueter wrote:
On Mon, May 23, 2011 at 08:51, Brendan Eich bren...@mozilla.com wrote:
Class syntax is like a lint brush for such features. If we add it, it will
accrete more semantics (with unambiguous syntax, I hope) over time. This is
just
Sugar is fine for defining classes (as opposed to defining types in terms of
the constructor) but I get a little worried when I see the 'extends'
keyword. I'm probably biased but I see many JavaScript trainees eager to
simulate classical inheritance because it fits right in their comfort zone.
The class syntax would be a great boon to the Closure Compiler. Much of
ADVANCED mode optimizations depends on understanding class relationships,
currently this means teaching it about each framework's extend or
inherit methods and each of their subtleties.
On Mon, May 23, 2011 at 4:10 AM,
On Monday, 2011-05-23 at 18:47 , John Lenz wrote:
The class syntax would be a great boon to the Closure Compiler. Much of
ADVANCED mode optimizations depends on understanding class relationships,
currently this means teaching it about each framework's extend or
inherit methods and each
On May 23, 2011, at 8:31 AM, Brendan Eich wrote:
On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
On 23.05.2011 14:17, Irakli Gozalishvili wrote:
Hi,
I think there lot's of proposals for ES.next that require syntax
On May 23, 2011, at 9:45 AM, Angus Croll wrote:
Sugar is fine for defining classes (as opposed to defining types in terms of
the constructor) but I get a little worried when I see the 'extends'
keyword. I'm probably biased but I see many JavaScript trainees eager to
simulate classical
On May 23, 2011, at 10:03 AM, Alex Russell wrote:
(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and
(B) the pain of doing correct super calls by hand.
I hope we can add the hazards of incorrectly adding mutable state to a
prototype and
On May 23, 2011, at 10:41 AM, Brendan Eich wrote:
On May 23, 2011, at 10:03 AM, Alex Russell wrote:
(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and
(B) the pain of doing correct super calls by hand.
I hope we can add the hazards of
1. More syntax means larger language surface, which adds complexity
more things to remember / learn. More things to consider in ES.next.next
Yup, languages almost always tend to get bigger over time since it's really
hard to remove features.
For me, the goal isn't to make the language as
this is going to get a little philosophical and not super technical so i apologize in advance.
i don't agree that expressiveness is necessarily a good thing. expressiveness comes with a cognitive overhead when reading and thinking about code, it's in your head, always. the more feature, the more
On Mon, May 23, 2011 at 8:51 AM, Brendan Eich bren...@mozilla.com wrote:
Class syntax is like a lint brush for such features. If we add it, it will
accrete more semantics (with unambiguous syntax, I hope) over time. This is
just inevitable, in my view. It makes me want to resist classes and
On Mon, May 23, 2011 at 10:41 AM, Brendan Eich bren...@mozilla.com wrote:
On May 23, 2011, at 10:03 AM, Alex Russell wrote:
(A) the boilerplate needed to set up a sub-prototype object with correct
constructor property, and
(B) the pain of doing correct super calls by hand.
I hope we
Using public to refer to an instance property seems totally weird to me.
For what it's worth, I agree. I'd prefer var or instance. I've already seen
at least one example of someone misinterpreting it and doing something like:
class C {
public someMethod() { ... }
}
Their intent was to
there are lots of ES.next features that let us do something that we could
not do at all previously (weak tables and refs are a good example). features
that enable new kinds of applications we couldn't previous build.
+1 on this point. There’s been a lot of discussion of syntactic sugar
If one has a class proposal with the prerequisite examples and grammar
specification, how does one propose this with a possible goal of an alternate
strawman?
On May 23, 2011, at 11:25 AM, Bob Nystrom rnyst...@google.com wrote:
On Mon, May 23, 2011 at 10:41 AM, Brendan Eich
On Mon, May 23, 2011 at 11:32 AM, Bob Nystrom rnyst...@google.com wrote:
Using public to refer to an instance property seems totally weird to me.
For what it's worth, I agree. I'd prefer var or instance. I've already
seen at least one example of someone misinterpreting it and doing something
Le 23/05/2011 20:15, Mikeal Rogers a écrit :
this is going to get a little philosophical and not super technical so
i apologize in advance.
i don't agree that expressiveness is necessarily a good thing.
expressiveness comes with a cognitive overhead when reading and
thinking about code, it's
On May 23, 2011, at 11:25 AM, Bob Nystrom wrote:
One thing I'd like the proposal to support, which it doesn't currently, is
initializers on instance property declarations. Then you could do:
class C {
public _list = [];
}
With that, you'll correctly get a new _list on each instance
On May 23, 2011, at 11:33 AM, Luke Hoban wrote:
there are lots of ES.next features that let us do something that we could
not do at all previously (weak tables and refs are a good example).
features that enable new kinds of applications we couldn't previous build.
+1 on this point.
34 matches
Mail list logo
