Allen Wirfs-Brock wrote:
On May 30, 2012, at 4:42 PM, Brendan Eich wrote:
What we agreed to last week: no |super| outside of classes in ES6,
no Object.defineMethod in ES6. That's what I recall and what the
notes say (re: |super|).
I also don't see the mention of defineMethod although I know
On 30 May 2012 14:52, Brendan Eich bren...@mozilla.com wrote:
Felix Böhm wrote:
Okay, fair point. But JSON.parse should do what it's name says: Parse
JSON. Ignoring keys is not an option.
JSON.parse must not treat __proto__ specially, per ES5. What's the problem
you see?
__proto__ can
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for
can. What guarantee are you trying to provide? What do you mean by might?
+1
I think
On 30 May 2012 22:33, Mark S. Miller erig...@google.com wrote:
My concern is indeed the overall complexity budget. And I agree. I'm happy
to have both of these if we can make some real complexity cuts elsewhere. I
look forward to that other conversation ;).
I have the same concern. The
On 30 May 2012 23:34, David Herman dher...@mozilla.com wrote:
On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
On Wed, May 30, 2012 at 5:22 PM, David Herman dher...@mozilla.com wrote:
array.{
pop();
pop();
pop();
};
path.{
moveTo(10, 10);
On 31 May 2012 10:44, Andreas Rossberg rossb...@google.com wrote:
On 30 May 2012 23:34, David Herman dher...@mozilla.com wrote:
On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
On Wed, May 30, 2012 at 5:22 PM, David Herman dher...@mozilla.com
wrote:
array.{
pop();
On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder t...@crowdersoftware.comwrote:
On 31 May 2012 10:44, Andreas Rossberg rossb...@google.com wrote:
On 30 May 2012 23:34, David Herman dher...@mozilla.com wrote:
On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
On Wed, May 30, 2012 at 5:22 PM,
From: T.J. Crowder
I'm worried this looks a lot like `with` -- with the same issues. Is the
idea that unqualified references would be _required_ to be properties of
the object in question?
This looks like a with regarding some points, but this is cleary not a with.
I think
var style
On 31 May 2012 11:05, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote:
On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder
t...@crowdersoftware.comwrote:
On 31 May 2012 10:44, Andreas Rossberg rossb...@google.com wrote:
On 30 May 2012 23:34, David Herman dher...@mozilla.com wrote:
On May
On 31 May 2012 11:18, T.J. Crowder t...@crowdersoftware.com wrote:
On 31 May 2012 11:05, Jussi Kalliokoski jussi.kallioko...@gmail.comwrote:
On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder
t...@crowdersoftware.comwrote:
On 31 May 2012 10:44, Andreas Rossberg rossb...@google.com wrote:
On
All,
I was going to lurk longer before raising this, and apologies if it's been
raised before, but the discussion of object extension literals sort of
brought it up.
TL;DR: I wonder if the object extension literal might reasonably become a
fit-for-purpose `with`. For years I've thought the
On 31 May 2012 11:30, François REMY fremycompany_...@yahoo.fr wrote:
o.{
a.b = 6;
c.f();
a.b = a.c; // !!
};
This is indeed an issue that could be solved using
o.{
.a.b = 6;
.c.f();
.a.b = .a.c;
}
Exactly my thought, and as it happens I was just
On 31 May 2012 11:33, T.J. Crowder t...@crowdersoftware.com wrote:
All,
I was going to lurk longer before raising this, and apologies if it's been
raised before, but the discussion of object extension literals sort of
brought it up.
TL;DR: I wonder if the object extension literal might
On 31 May 2012 12:52, T.J. Crowder t...@crowdersoftware.com wrote:
2. I originally envisioned this as a statement (of course, I was originally
thinking we'd have a new keyword, until the object extension literal
discussion), but it could be an expression; if so, presumably the result of
the
On 31 May 2012 12:12, Andreas Rossberg rossb...@google.com wrote:
On 31 May 2012 12:52, T.J. Crowder t...@crowdersoftware.com wrote:
2. I originally envisioned this as a statement (of course, I was
originally
thinking we'd have a new keyword, until the object extension literal
I really like(d) the mustache proposal but unfortunately reached the
same conclusion : too complicate and confusing for what it brings. It's
surprising that the fundamental difference between Put and DOP was
unknown from almost everybody (including myself), then a rapid and easy
conclusion
On May 31, 2012, at 1:37 AM, gaz Heyes wrote:
On 30 May 2012 14:52, Brendan Eich bren...@mozilla.com wrote:
Felix Böhm wrote:
Okay, fair point. But JSON.parse should do what it's name says: Parse JSON.
Ignoring keys is not an option.
JSON.parse must not treat __proto__ specially, per ES5.
On May 31, 2012, at 2:27 AM, Andreas Rossberg wrote:
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for
can. What guarantee are you
Hello,
reacting to super only in classes, I'd like to propose widening it
just a little bit:
1. Allow super in every concise methods (in classes, as well as out of
them).
1a. constructor method in class definition is also rated as concise
method for the purpose of 1.
2. Allow
function
On Wed, May 30, 2012 at 8:40 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On May 30, 2012, at 5:14 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I now could be quite happy with the paren based cascade idea that Brendan
suggested last night. I'm surprised that no one has commented
On 31 May 2012 18:03, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 31, 2012, at 2:27 AM, Andreas Rossberg wrote:
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out)
On Thu, May 31, 2012 at 6:05 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder
t...@crowdersoftware.comwrote:
On 31 May 2012 10:44, Andreas Rossberg rossb...@google.com wrote:
On 30 May 2012 23:34, David Herman dher...@mozilla.com
On Thu, May 31, 2012 at 2:27 AM, Andreas Rossberg rossb...@google.comwrote:
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for
can. What
On Thu, May 31, 2012 at 12:51 PM, Mark S. Miller erig...@google.com wrote:
We do not complain that a safe program might need to be revised before a
type checker can vouch that it is safe.
As the author of a type checker, let me assure you that while you
might not complain, your users certainly
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
A function is free to _document_ it as part of its
contract, though.
Contracts are much more useful if they are enforced by the
system, the language and runtime in this case.
Cheers - BIll
On 31 May 2012 19:01, Bill Frantz fra...@pwpconsult.com wrote:
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
A function is free to _document_ it as part of its
contract, though.
Contracts are much more useful if they are enforced by the system, the
language and runtime
On Fri, May 25, 2012 at 11:01 AM, Axel Rauschmayer a...@rauschma.de wrote:
Great! Suggestion: one file per chapter (faster, especially on mobile
devices).
The TOC either in its own file or before the copyright information would be
more convenient, too. I'd expect it to always be the starting
(private reply)
On May 31, 2012, at 1:53 AM, Herby Vojčík wrote:
P.S.: It was told that there are some problems with super -- what are they?
I think the problem is that some committee members just don't understand the
normal OO semantics of super and how it is used in OO inheritance. In
On May 31, 2012, at 2:52 AM, T.J. Crowder wrote:
I'm worried this looks a lot like `with` -- with the same issues.
No. No.
This does not involve the object with the scope chain in any way.
Is the idea that unqualified references would be _required_ to be properties
of the object in
On Thu, May 31, 2012 at 1:32 PM, Andreas Rossberg rossb...@google.comwrote:
On 31 May 2012 19:01, Bill Frantz fra...@pwpconsult.com wrote:
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
A function is free to _document_ it as part of its
contract, though.
well this is embarrassing...
I stand by my perception, but it isn't something I would normally share in a
public list.
I apologize if anybody is offended.
Allen
On May 31, 2012, at 11:07 AM, Allen Wirfs-Brock wrote:
(private reply)
On May 31, 2012, at 1:53 AM, Herby Vojčík wrote:
On May 31, 2012, at 11:13 AM, Russell Leggett wrote:
If you reframe the problem as |this| just being another parameter, this whole
debate seems quite silly to me. Any function that is written to have a |this|
value be dynamic, and possibly set by the caller can be rewritten as a
function
Thanks, Dave.
Bottom-citing here, and again I'm a sinner too, but could everyone on
this nicely long thread take a breath and remember two things:
1. We aren't going to reform 'with' for ES6 or Harmony. It's banned in
strict mode, there due to 1JS in the non-strict mode of the language,
not
On May 31, 2012, at 4:12 AM, Andreas Rossberg wrote:
4. The leading dot seems, to me, to be more explicit than just having the
first symbol on the left being implicitly a property the object. EIBTI
I agree with that.
As I said in another thread, it's not going to happen because of the ASI
On May 25, 2012, at 5:29 AM, Rick Waldron wrote:
On Fri, May 25, 2012 at 2:10 AM, François REMY fremycompany_...@yahoo.fr
wrote:
While we're at it, I had an idea to allow to avoid the function*() {} syntax:
why not yield [noLineTerminator] return ?
This approach expects all future
On 31 May 2012 19:24, David Herman dher...@mozilla.com wrote:
On May 31, 2012, at 4:12 AM, Andreas Rossberg wrote:
4. The leading dot seems, to me, to be more explicit than just having
the
first symbol on the left being implicitly a property the object. EIBTI
I agree with that.
As I
On Thu, May 31, 2012 at 4:46 PM, T.J. Crowder t...@crowdersoftware.comwrote:
On 31 May 2012 19:24, David Herman dher...@mozilla.com wrote:
As I said in another thread, it's not going to happen because of the ASI
hazard.
Dave
Expand/link? How does this cause an ASI issue (that can't be
I think there's a core confusion at the heart of this thread. Let's restart
operationally.
If one did have such a predicate, when would some other program actually
use it? In other words, for the predicate you have in mind, please give a
concrete example where a program would usefully say
if
On 31 May 2012 22:17, Rick Waldron waldron.r...@gmail.com wrote:
On Thu, May 31, 2012 at 4:46 PM, T.J. Crowder t...@crowdersoftware.comwrote:
On 31 May 2012 19:24, David Herman dher...@mozilla.com wrote:
As I said in another thread, it's not going to happen because of the ASI
hazard.
On 31 May 2012 19:21, Brendan Eich bren...@mozilla.org wrote:
Thanks, Dave.
Bottom-citing here, and again I'm a sinner too, but could everyone on this
nicely long thread take a breath and remember two things:
1. We aren't going to reform 'with' for ES6 or Harmony. It's banned in
strict
On Thu, May 31, 2012 at 5:40 PM, Mark S. Miller erig...@google.com wrote:
snip
If the predicate means what I think it should mean, I can offer some
examples of when I would do this. If the predicate means anything else
that's been advocated on this thread, such as fat arrow or bound, then I
Thanks Rick. For lurkers:
o.{
foo() // No semi
.bar() // Is this o.bar()? or .bar() on the result of foo()?
};
I've been following and have read back in the thread, but I'm not seeing a
how .bar() would be allowed?
Point me in the right direction!
Rick
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
I think there's a core confusion at the heart of this thread. Let's restart
operationally.
If one did have such a predicate, when would some other program actually use
it? In other words, for the predicate you have in mind, please give
If you are using call anyway and passing the array as thisObj there, why do
you need to do the bind at all?
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, May 31, 2012 at 3:08 PM, Rick Waldron waldron.r...@gmail.comwrote:
I'm going to take a stab at this, because I think I have a good
understanding of what the JSFixed group is concerned about...
Hi Rick, thanks. That's exactly what I was hoping for.
// Imaginary DOM library
DOM
T.J. Crowder wrote:
My point is that the discussion of object extension literals was
clearly headed toward being a new `with`,
No, this is what Dave was objecting to. It's careless to say new
'with' if you do not mean dynamic scope, specifically object on the
scope chain. No one meant that,
On Thu, May 31, 2012 at 3:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
For example, somebody might want to replace the existing apply, call, and
bind methods, with versions that throw an error when invoked on a fat arrow
or bound function. For example:
(function replaceCall() {
Rick Waldron wrote:
Thanks Rick. For lurkers:
o.{
foo() // No semi
.bar() // Is this o.bar()? or .bar() on the result of foo()?
};
I've been following and have read back in the thread, but I'm not
seeing a how .bar() would be allowed?
In the with example
Early normalization never became a standard? Boy, I've been away from this
stuff for too long… Does this mean that all the other Web standards that were
going to adhere to early normalization do something similar to what you're
proposing? Or do they also just assume, even though it never
On May 31, 2012, at 4:17 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 3:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
For example, somebody might want to replace the existing apply, call, and
bind methods, with versions that throw an error when invoked on a fat arrow
or
On 1 June 2012 00:28, Brendan Eich bren...@mozilla.org wrote:
In the with example that Dave gave:
with (obj) {
foo() // no semi
.bar = 12
}
it's all allowed as in no syntax error (to correct via ASI) and no
restricted production (to make line termination
T.J. Crowder wrote:
On 1 June 2012 00:28, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
In the with example that Dave gave:
with (obj) {
foo() // no semi
.bar = 12
}
it's all allowed as in no syntax error (to correct via ASI)
On Thu, May 31, 2012 at 7:01 PM, Mark S. Miller erig...@google.com wrote:
snip
// Imaginary DOM library
DOM = {};
// This function accepts a function as it's second argument,
// what happens when its a bound function? I'd like write the
// API in a way that is friendly to both types of
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
Wouldn't this mean that fat arrow functions inherit call, apply and bind
as well? (I may have misunderstood this aspect)
I believe they do.
Yes, sorry, that is a typo - I put this example together quickly, I
On Thu, May 31, 2012 at 4:44 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I don't think I argued that for isBound although I certainly would make
that argument about arrow functions in general.
In this case, I'm assuming a debugging scenario. Somebody is passing arrow
functions through
On 1 June 2012 00:51, Brendan Eich bren...@mozilla.org wrote:
Dave's cascade proposal:
http://blog.mozilla.org/**dherman/2011/12/01/now-thats-**a-nice-stache/http://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/
Thanks. With a great deal of respect, I'm not seeing how that
Mark S. Miller wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
Wouldn't this mean that fat arrow functions inherit call, apply
and bind as well? (I may have misunderstood this aspect)
I believe they do.
Yes, and both
T.J. Crowder wrote:
On 1 June 2012 00:51, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Dave's cascade proposal:
http://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/
Thanks. With a great deal of respect, I'm not seeing how that isn't
with-lite
Wouldn't this mean that fat arrow functions inherit call, apply
and bind as well? (I may have misunderstood this aspect)
I believe they do.
Yes, and both apply and call are useful on arrows, even though |this|
cannot be overridden. Arguments still matter ;-).
My previous
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.com wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
Could you post a corrected example? Thanks.
To reduce any confusion, I've posted the corrected code here:
https://gist.github.com/2847608
Rick
On Thu, May 31, 2012 at 5:41 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.comwrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
Could you post a corrected example? Thanks.
To reduce any
On May 31, 2012, at 5:31 PM, Brendan Eich wrote:
Mark S. Miller wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
Wouldn't this mean that fat arrow functions inherit call, apply
and bind as well? (I may have
Resending as plain text to avoid the unpredictable mailer-inserted spacing.
On Thu, May 31, 2012 at 5:41 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.com wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.com
On May 31, 2012, at 5:18 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 4:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I don't think I argued that for isBound although I certainly would make that
argument about arrow functions in general.
In this case, I'm assuming a
On Thursday, May 31, 2012 at 8:49 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 5:41 PM, Rick Waldron waldron.r...@gmail.com
(mailto:waldron.r...@gmail.com) wrote:
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.com
(mailto:erig...@google.com) wrote:
On
On 1 June 2012 01:40, Brendan Eich bren...@mozilla.org wrote:
Let's be precise. You keep bringing 'with' up but it's not relevant to the
cascade proposal, going by Dave's definitions. If you have the appearance
of 'with' concern I call out above, let's argue about that. It's a good
one (again
On Thu, May 31, 2012 at 6:06 PM, Rick Waldron waldron.r...@gmail.com wrote:
The original API allowed me to pass an explicitly bound callback (whether it
was by bind or fat arrow) and have that binding take precendence over a
default behavior.
Hi Rick, I don't understand that sentence. Can you
On Thu, May 31, 2012 at 5:56 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If I understood it, I would probably prefer what you are proposing.
However, I suspect that many JS programs will conceptually equate bond
this with bound functions and arrow functions and not think about equating
On May 31, 2012, at 5:30 PM, T.J. Crowder wrote:
On 1 June 2012 00:51, Brendan Eich bren...@mozilla.org wrote:
Dave's cascade proposal:
http://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/
Thanks. With a great deal of respect, I'm not seeing how that isn't
with-lite with
On May 31, 2012, at 7:08 PM, T.J. Crowder wrote:
On 1 June 2012 01:40, Brendan Eich bren...@mozilla.org wrote:
Let's be precise. You keep bringing 'with' up but it's not relevant to the
cascade proposal, going by Dave's definitions. If you have the appearance of
'with' concern I call out
On May 31, 2012, at 7:23 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 5:56 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If I understood it, I would probably prefer what you are proposing.
However, I suspect that many JS programs will conceptually equate bond
this with bound
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Mark S. Miller
Sent: Thursday, May 31, 2012 22:24
Non-strict mode is so bizzarre that I wouldn't be surprised, but I can't
think of an example. Is my proposed rule unsound
On May 31, 2012, at 6:06 PM, Rick Waldron wrote:
The original API allowed me to pass an explicitly bound callback (whether it
was by bind or fat arrow) and have that binding take precendence over a
default behavior.
I think you might still be missing a key point: if `callbackFn` is a bound
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
if (isBoundOrWhateverWeCallIt(f)) {
//... do something
} else {
//... do something else
}
If the predicate means what I think it should mean, I can offer some examples
of when I would do this.
Could you? I
FWIW, I tried very hard to come up with an example but failed. If I understand
it correctly fat arrow acts is a helper for `var self = this`. Then it no
matter what the underlying method does the following code will simply ignore
`this`:
var self = this;
DOM.each(div, function (el) {
On Thu, May 31, 2012 at 10:42 PM, David Herman dher...@mozilla.com wrote:
On May 31, 2012, at 6:06 PM, Rick Waldron wrote:
The original API allowed me to pass an explicitly bound callback
(whether it was by bind or fat arrow) and have that binding take
precendence over a default behavior.
Yes, you're exactly right - I hadn't realized this would be the behavior
-- but it makes perfect sense seeing it from a different perspective.
By different, I mean correct ;)
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
T.J. Crowder wrote:
On 1 June 2012 01:40, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Let's be precise. You keep bringing 'with' up but it's not
relevant to the cascade proposal, going by Dave's definitions. If
you have the appearance of 'with' concern I call
On Thu, May 31, 2012 at 7:44 PM, David Herman dher...@mozilla.com wrote:
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
if (isBoundOrWhateverWeCallIt(f)) {
//... do something
} else {
//... do something else
}
If the predicate means what I think it should
David Herman wrote:
Now the cascade:
array.{
pop()
pop()
};
That looks like `with`, it acts like `with`,
No, it doesn't, and it would be really helpful if you would try to
understand why it doesn't.
So the key here is prototype chain vs. scope chain. 'with' extends the
scope
On May 31, 2012, at 9:31 PM, Brendan Eich wrote:
This may seem not much of a difference, but it's major not only due to the
typo and array-not-an-Array-instance cases. The scope chain extension is
costly and forces deoptimization in common implementations. And of course
'with' is banned in
On May 31, 2012, at 9:50 PM, David Herman wrote:
...but it could be captured by the `with` object or one of its properties.
s/properties/prototypes/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On May 31, 2012, at 9:50 PM, David Herman wrote:
Whereas with cascades, you'd get:
var obj = {
log: console.log.bind(console),
foo: function() { Object.prototype.bar = captured }
};
var bar = local variable;
with (obj) {
log(bar); // local variable
Right, that capture-in-prototype case does not differ due to both
cascade desugaring and 'with' searching the head object including its
prototype chain.
But with a deeper scope chain, and bar not bound in the innermost scope,
then 'with' allows an evil interloping function to shadow (or
Brendan Eich wrote:
you're just rehashing a concern based on appearances
which (I want to be clear; sorry for harshing on the 'with' point) is a
valid concern. We should discuss it directly, no 'with'-semantics mixed in.
/be
___
es-discuss mailing
It's become clear to me that mustache syntax is not well motivated. As a simple
update for objects, there's little it can do that Object.extend couldn't do. I
thought with my cascades proposal that it might gain more justification (to
allow the fluent aka chainable style even for methods that
On May 31, 2012, at 1:54 PM, Allen Wirfs-Brock wrote:
On May 31, 2012, at 1:53 AM, Herby Vojčík wrote:
Hello,
reacting to super only in classes, I'd like to propose widening it just a
little bit:
1. Allow super in every concise methods (in classes, as well as out of them).
Basically
87 matches
Mail list logo
