On Mar 29, 2011, at 3:30 PM, Bob Nystrom wrote:
> C#, CoffeeScript, and other languages use -> to link a formal parameter list
> to a function body, which requires bottom-up parsing in general (with comma
> as operator, as JS, C++, and C have; plus Harmony's destructuring and default
> paramete
2011/3/29 Mike Samuel :
> 2011/3/29 Bob Nystrom :
>> Wouldn't => work the same way?
>> (a, b) =>
>> It parses "(a, b)" thinking it's a grouped comma operator (not exactly a
>> common expression FWIW), then it hits "=>" realizes it's a function
>> parameter decl, and then either backtracks or ju
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
> wrote:
>>
>> JavaScript up to this point seems to have done a pretty good job of
>> balancing the OO and functional perspective within the language. However, I
>> think removing the
2011/3/29 Bob Nystrom :
> Wouldn't => work the same way?
> (a, b) =>
> It parses "(a, b)" thinking it's a grouped comma operator (not exactly a
> common expression FWIW), then it hits "=>" realizes it's a function
> parameter decl, and then either backtracks or just transforms the left-hand
> A
>
> C#, CoffeeScript, and other languages use -> to link a formal parameter
> list to a function body, which requires bottom-up parsing in general (with
> comma as operator, as JS, C++, and C have; plus Harmony's destructuring and
> default parameter value proposals).
>
I'm not a parsing expert, b
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
wrote:
>
> JavaScript up to this point seems to have done a pretty good job of balancing
> the OO and functional perspective within the language. However, I think
> removing the specialness of "this" and the implicit this parameter may be a
> s
On Mar 29, 2011, at 1:12 PM, P T Withington wrote:
>
> If I had a vote, it would be for a way to explicitly name the `-1th` argument
> to a function. And I would wish for it to be available in all function
> forms, defaulting to using the legacy name `this`, if not otherwise
> specified. I
On Mar 29, 2011, at 11:19 AM, Allen Wirfs-Brock wrote:
> The original discussion in January added explicit naming and lexical scoping
> of the implicit "this" parameter to # function declarations. In January we
> didn't settle on a syntax but in March we seem to be converging on something
> li
On Mar 29, 2011, at 12:14 AM, Dmitry A. Soshnikov wrote:
> On 29.03.2011 2:51, Allen Wirfs-Brock wrote:
>>
>> ...
>
> Regarding classes in general I have the following table of "classes" kinds:
>
> |first-class | second-class (or "first-order")
> |
Mixins are a great idea. Whatever decision is made about the position and
name of the inheritance declaration, they add a lot of value and are very
easy to understand.
A couple of related ideas:
class Vector {
}
"uses" looks like a better fit. It's shorter and it's already used by many
docu
On 2011-03-29, at 14:19, Allen Wirfs-Brock wrote:
> I'll leave it to reader to weigh the above pros and cons. But I do have a
> closing statement:
>
> There is a decades long disagreement among designers/users of function and
> object-oriented languages. OO proponents think there is something
On Mar 29, 2011, at 7:28 AM, David Herman wrote:
> On Mar 29, 2011, at 7:26 AM, David Herman wrote:
>
>> This is what Sam is referring to -- we've been talking about exactly such a
>> feature.
>
> Sorry if that wasn't clear: at the last face-to-face we talked about allowing
> you to give your
I am really astonished to hear protection keys being thought
of as "brittle" under transformation: that is just the opposite
of what they are about!
Sorry to astonish you. :)
No problem!-) I was just afraid of the idea being misunderstood
or being associated with fear-inducing phrasing, eit
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
>
>
> PS A propos of nothing, the ^this syntax probably doesn't work because of
> ASI; try parsing:
>
>x = y
>^this.foo()
>
I specified that "^this" was a lexical token so I ASI should work fine. But
you would have to say
y ^ /
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
> This is what Sam is referring to -- we've been talking about exactly such a
> feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own custom name for the |this|-parameter, so that you could
c
Besides. I'd like to propose also :: syntax (can it break LL handwritten
parsers?) to improve monkey-patching of the dynamic classes. It uses in
C++ and also in Coffee as a sugar for "prototype" property.
Point::create = function () {
...
};
desugars into:
Point.prototype.create = function
This is what Sam is referring to -- we've been talking about exactly such a
feature. I continue to believe that something like the ^this feature we've been
talking about is as likely to introduce bugs as it is to fix bugs. It's like
special language support for off-by-one errors.
Dave
PS A pro
On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote:
> I agree entirely that it goes with the existing fixed implicit |this|
> binding -- I just think that cuts the other way. The reason we're
> having this discussion is that the existing behavior of |this| isn't
> always what you want, and is har
On Tue, Mar 29, 2011 at 12:12 AM, Allen Wirfs-Brock
wrote:
>
> (I think I'm the only one to use the syntax ^this in a proposal so I'm not
> sure where 1,3,4 (at least using ^this syntax) came from.
Well, I wasn't sure if you meant 1 or 2, and other people had
suggested 3 and 4 (but I think usin
On Mar 28, 2011, at 10:35 AM, Allen Wirfs-Brock wrote:
> On Mar 27, 2011, at 11:13 AM, David Herman wrote:
>
>> To be fair, your suggestion is more moderate than de Bruijn, although it's
>> not clear whether you're proposing the ability to refer to shadowed bindings
>> of *all* variables or
On 29.03.2011 2:51, Allen Wirfs-Brock wrote:
On Mar 28, 2011, at 1:53 PM, Dmitry A. Soshnikov wrote:
Exactly. "Classes" are not about just the "class" keyword, but about
the _ability to classify_, i.e. to program in classified (i.e. with
object-patterned programming). JS supports (and suppor
On Tue, Mar 29, 2011 at 4:16 AM, Erik Arvidsson wrote:
> We (Chromium/V8) discussed introducing 'self' as a a way to get the
> lexically bound 'this'. The main issue we could think of was that it
> might be hard for users to know when to use '^this' vs when to use
> 'this'.
>
`self` will almost d
22 matches
Mail list logo
