On Mon, Mar 26, 2012 at 10:37 PM, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
The conformance clause doesn't say anything about the interpretation of
(UTF-16) code units as code points. To check conformance with C1, you have
to look at how the resulting code points are actually
Erik Corry wrote:
Steven Levithan wrote:
- Make \d\w\b Unicode-aware.
I think we should leave these alone. They are concise and useful and
will continue to be so when /u is the default in Harmony code.
Instead we should introduce \p{...} immediately which provides the
same functionality.
Andrea Giammarchi wrote:
One thing does not scale well in current prototype logic, what has
been flagged in the proto is not inherited with same descriptor per
each instance ( arguable if expected or not )
You mean when the prototype property is shadowed in the instance by a
property of the
Yep, I mean exactly that ... technically inconsistent due getters/setters
... e.g.
function C() {
this.willThrow = whatever;
}
Object.defineProperty(C.prototype, willThrow, {
set: function () {
throw doh!;
}
});
so the __proto__ there works as expected unless we don't use defineGetter
On Mon, Mar 26, 2012 at 10:38 PM, Brendan Eich bren...@mozilla.com wrote:
It's your point about no data properties in the vtable, or the flip side
of it. The for-in loop was meant to enumerate built-ins' expando and (in a
few cases, ES3 made this more random) data-but-not-function-valued
This begs the question of what is the point of C1.
On Tue, Mar 27, 2012 at 9:13 AM, Mark Davis ☕ m...@macchiato.com wrote:
That would not be practical, nor predictable. And note that the 700K
reserved code points are also not to be interpreted as characters; by your
logic all of them would
On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote:
This is actually one of the reasons I still come down on constructor over
new - I'd really like to discourage screwing around with
ctor.prototype.constructor. That always felt like a major wart IMO. Making
it ReadOnly/DontDelete would be
The point of C1 is that you can't interpret the surrogate code point U+DC00
as a *character*, like an a.
Neither can you interpret the reserved code point U+0378 as a *character*,
like a b.
--
Mark https://plus.google.com/114199149796022210033
*
*
*— Il meglio è
On Mar 27, 2012, at 13:10, David Herman dher...@mozilla.com wrote:
I recognize the C.prototype.constructor idiom already exists, but it's a weak
idiom. I'm not crazy about the idea of strengthening a problematic but
currently unreliable and rarely used idiom.
Dave
Speaking as a dev, I
Domenic Denicola wrote:
On Mar 27, 2012, at 13:10, David Hermandher...@mozilla.com
wrote:
I recognize the C.prototype.constructor idiom already exists, but
it's a weak idiom. I'm not crazy about the idea of strengthening a
problematic but currently unreliable and rarely used idiom.
Dave
On Tue, Mar 27, 2012 at 1:09 PM, David Herman dher...@mozilla.com wrote:
On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote:
This is actually one of the reasons I still come down on constructor
over new - I'd really like to discourage screwing around with
ctor.prototype.constructor. That
On Mar 26, 2012, at 11:57 PM, Erik Corry wrote:
Add /U to mean old-style regexp literals in Harmony code (analogous to
/s and /S which have opposite meanings).
Are we sure this has enough utility to be worth adding? - it seems unlikely
that programmers are going to often have cause to
Russell Leggett wrote:
Can we make it writable:false, configurable:true? Of course, that
would only be a minor deterrent from changing it around, but maybe
just enough?
This has zero integrity, so is IMHO worse than worthless -- it's
misleading. Not that anyone will count on it, but stopping
What Tab said about having right versions for the binary operators.
Otherwise you can't properly handle number + decimal or number +
complex, e.g.
The right and left methods proposed in
http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies seems
worth a look, as well as the OOPSLA
So, if as a result of a policy of converting any UTF-16 code unit sequence
to a code point sequence one ends up with an unpaired surrogate, e.g.,
\u{00DC00}, then performing a predicate on that code point, such as
described in D21 (e.g., IsAlphabetic) would entail interpreting it as an
abstract
John J Barton wrote:
We do have a problem among for-in/keys() and enumeration: we do not
have good solutions to separately enumerate functions (methods) and
data. That is the problem. Solving this problem be willy-nilly
non-enumeration of methods is not a good path. Ok maybe willy-nilly
is a
On Tue, Mar 27, 2012 at 2:59 PM, Brendan Eich bren...@mozilla.com wrote:
Russell Leggett wrote:
Can we make it writable:false, configurable:true? Of course, that would
only be a minor deterrent from changing it around, but maybe just enough?
This has zero integrity, so is IMHO worse than
I never liked simulating double dispatch in a single dispatch language and once
I came in contact with Common Lisp, I found out why: For some problems,
multiple dispatch and generic functions (in CL terminology) are a better fit,
conceptually.
The obvious contra argument is that it would add a
Just a bit related and perhaps of interest: Back when I believed in
operator overloading, I wrote a package to allow C++ classes to inherit
consistent overloading. The package consisted of templatized base classes
that defined say the binary + operator in terms of +=. The base class
parameter was
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
Use = only with an expression body (do-expressions if accepted allow
statements and combined with = compete with block-lambdas).
Use - only with body block, as for long-form function.
I deferred other accretions.
In a
ok, i'll accept your position at this point and drop my comment; i suppose
it is true that if there are already unpaired surrogates in user data as
UTF-16, then having unpaired surrogates as code points is no worse;
however, it would be useful if there were an informative pointer from the
spec
Looks good. Not sure if the different rules for the body aren’t confusing.
On Mar 27, 2012, at 21:43 , Brendan Eich wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
Use = only with an expression body (do-expressions if accepted allow
statements and combined with
Yes, please. This looks and feels like the proposal from Dave Herman that I
supported (and enjoyed writing examples for) the most.
Very exciting to see this moving along and finding wider support.
Rick
On Tue, Mar 27, 2012 at 4:37 PM, Axel Rauschmayer a...@rauschma.de wrote:
Looks good. Not
Great to see the arrow syntax proposal moving forward.
I think I missed a step though in the reasoning for moving to this proposal vs.
the previous arrow proposal. What problem did the previous proposal have that
is addressed with the new proposal?
There's a couple concerns I have with
On Tue, Mar 27, 2012 at 3:43 PM, Brendan Eich bren...@mozilla.com wrote:
http://wiki.ecmascript.org/**doku.php?id=strawman:arrow_**function_syntaxhttp://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
Use = only with an expression body (do-expressions if accepted allow
On Mar 27, 2012, at 5:08 PM, Luke Hoban lu...@microsoft.com wrote:
Great to see the arrow syntax proposal moving forward.
I think I missed a step though in the reasoning for moving to this proposal
vs. the previous arrow proposal. What problem did the previous proposal have
that is
We went over this in the thread Isaac started. You'd need a [no LineTerminator
here] between ) and {, and then the syntax looks too much like a juxtaposed
parenthesized expression and block.
The latter problem, a lack of syntactic distinctiveness, also felled there
entry mooted {(x)x}
[snip]
I think fully TCP- compliant do expressions are pure win, FTR.
I second this, of course, based solely on the experience I had writing up
these examples:
https://gist.github.com/2013909
https://github.com/rwldrn/popcorn-js/compare/tri-lambda
On Mar 27, 2012, at 5:28 PM, Brendan Eich bren...@mozilla.com wrote:
We went over this in the thread Isaac started. You'd need a [no
LineTerminator here] between ) and {, and then the syntax looks too much like
a juxtaposed parenthesized expression and block.
The latter problem, a lack of
Great to see the arrow syntax proposal moving forward.
I think I missed a step though in the reasoning for moving to this
proposal vs. the previous arrow proposal. What problem did the previous
proposal have that is addressed with the new proposal?
The ambiguity between a block body and
I think fully TCP- compliant do expressions are pure win, FTR.
I second this, of course, based solely on the experience I had writing up
these examples:
https://gist.github.com/2013909
https://github.com/rwldrn/popcorn-js/compare/tri-lambda
Luke Hoban wrote:
The do expressions serve a separate purpose of changing the meaning of return
(but not break and continue)
Dave proposed at
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021000.html
that do expressions be fully TCP compliant. No way to be half-pregnant :-/.
/be
Luke Hoban wrote:
The do expressions serve a separate purpose of changing the meaning of
return (but not break and continue)
Dave proposed at
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021000.html
that do expressions be fully TCP compliant. No way to be half-pregnant :-/.
Luke Hoban wrote:
The future hostility concern doesn't seem so serious as to kill this proposal -
especially relative to the value of simple short function syntax. The future
hostility would only seem to come in if we introduced new object literal syntax
which was truly ambiguous with
On Tue, Mar 27, 2012 at 7:46 PM, Luke Hoban lu...@microsoft.com wrote:
Luke Hoban wrote:
The do expressions serve a separate purpose of changing the meaning of
return (but not break and continue)
Dave proposed at
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021000.html
I like the = syntax, but I'm not convinced regarding single arrow
functions.
Some observations:
1) A shorter function syntax for classic functions doesn't seem to carry
much payoff.
2) Generally, users will want closures to have lexically-bound this. The
strawman makes this possible via either
But my primary point was just that in Rick's examples, there doesn't
appear to be any reliance on TCP at all. Had = supported blocks on the
RHS as in the original arrow proposal, all the code samples would be
simpler, simply removing the 'do'. I believe this will generally be true
too.
Luke Hoban wrote:
I actually think it's worth starting simple here (maximal minimalism again).
There is a lot of value in just having shorthand for exactly what 'function' is
used fortoday. Only statement bodies, no lexical this, nothing fancy for
nullary parameter lists. That alone would
Kevin Smith wrote:
I like the = syntax, but I'm not convinced regarding single arrow
functions.
Me neither.
Some observations:
1) A shorter function syntax for classic functions doesn't seem to
carry much payoff.
Only six letters.
2) Generally, users will want closures to have
Brendan Eich wrote:
Kevin's analysis contradicts your assertion. Expression-bodied
functions with bound |this| (or var self=this outside) predominate in
the code he surveyed.
See thread headed by this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021126.html
/be
No, the strawman says = *always* lexically binds |this|. How was it
unclear? I will fix it.
Yes - I understood that. My point (and *I* was probably being unclear -
it's late here on the east coast) was that if you want lexically bound this
for multistatement closures, you can choose
(x)
But aren't non-BTFs rare based on your (revised and original) measurements?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
But aren't non-BTFs rare based on your (revised and original) measurements?
When you take out the object literal methods, that's right.
The precise way to say it would be that ~90% of function expressions in the
code I analyzed were either object literal methods or did not depend on
dynamic
Getting back to the new vs. constructor issue:
The only real practical benefit to using constructor is that, if we use
new, it makes it a little bit harder to create a method named new:
class C {
constructor() {}
new() {}
}
// vs
class C {
new() {}
new()
Kevin Smith wrote:
That's exactly the reason I'm suggesting lexically bound |this| for
- functions, because outside of methods (which already have
shorter syntax, either via object literal extensions or classes),
there doesn't appear to be a great need for function expressions with
dynamic
On Mar 27, 2012, at 12:03 PM, Brendan Eich wrote:
What Tab said about having right versions for the binary operators.
Otherwise you can't properly handle number + decimal or number + complex, e.g.
yes you can:
Number.prototype.@operatorMinus = function(rval) {return
On Tuesday, March 27, 2012 at 9:54 PM, Luke Hoban wrote:
But my primary point was just that in Rick's examples, there doesn't
appear to be any reliance on TCP at all. Had = supported blocks on
the RHS as in the original arrow proposal, all the code samples would
be
On Mar 27, 2012, at 12:18 PM, Axel Rauschmayer wrote:
I never liked simulating double dispatch in a single dispatch language and
once I came in contact with Common Lisp, I found out why: For some problems,
multiple dispatch and generic functions (in CL terminology) are a better fit,
I hate the CoffeeScript deviation, though. It's just confusing for anyone
who ever learned that fat-arrow binds |this| and thin-arrow doesn't.
True. On the other hand, all arrows bind |this| is also quite simple and
easy to remember.
If the use-case for block bodies with bound |this| is
On Mar 27, 2012, at 10:36 PM, Kevin Smith khs4...@gmail.com wrote:
But aren't non-BTFs rare based on your (revised and original) measurements?
When you take out the object literal methods, that's right.
The precise way to say it would be that ~90% of function expressions in the
code I
Brendan Eich wrote:
Kevin's analysis contradicts your assertion. Expression-bodied
functions with bound |this| (or var self=this outside) predominate in
the code he surveyed.
See thread headed by this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021126.html
Yeah
51 matches
Mail list logo
