On Mar 24, 2012, at 11:23 PM, Norbert Lindenberg wrote:
> On Mar 24, 2012, at 12:21 , David Herman wrote:
>
>> I'm still getting up to speed on Unicode and JS string semantics, so I'm
>> guessing that I'm missing a reason why that wouldn't work... Presumably the
>> JS source of the regexp liter
One thing that I still would add (and haven't seen mentioned in the proposal)
are computed property names. Manually creating private names is not a problem,
neither is using this[] to add private instance data properties. But having to
add private methods externally to the class declaration woul
On Mar 24, 2012, at 4:32 PM, Norbert Lindenberg wrote:
> One concern: I think code point based matching should be the default for
> regex literals within modules (where we know the code is written for Harmony).
This idea makes me nervous. Partly because I think we should keep the set of
semanti
On Mar 24, 2012, at 5:54 PM, Allen Wirfs-Brock wrote:
> I primarily favor sticking with "constructor" because the
> safety/maximally-miminal proposal is all about being conservative...
I think you'll find what I'm saying is as conservative as what you've been
advocating. Your reply demonstrates
On Mar 24, 2012, at 12:21 , David Herman wrote:
[snip]
>> As for whether the switch to code-point-based matching should be universal
>> or require /u (an issue that your proposal leaves open), IMHO it's better to
>> require /u since it avoids the need for transforming \u[\u-\u]
>>
It's easy to provide this function, but in which situations would it be useful?
In most cases that I can think of you're interested in far more constrained
definitions of validity:
- what are valid ECMAScript identifiers?
- what are valid BCP 47 language tags?
- what are the characters allowed in
Allen Wirfs-Brock wrote:
To actually add a computed function as the value of a prototype object
property within the class definition is pretty much the same thing as
defining an arbitrary valued prototype data property. Defining
non-method prototype properties is one of the features that we h
On Mar 24, 2012, at 7:29 PM, Brendan Eich wrote:
> David Herman wrote:
>> On Mar 24, 2012, at 3:01 PM, Nadav Shesek wrote:
>>
>>> What about setting arbitrary expressions as the value for prototype
>>> methods? Being able to use higher-order functions to dynamically create
>>> functions is ver
David Herman wrote:
On Mar 24, 2012, at 3:01 PM, Nadav Shesek wrote:
What about setting arbitrary expressions as the value for prototype methods? Being able
to use higher-order functions to dynamically create functions is very important for
functional style programming. I use it very often to
Lasse Reichstein wrote:
The problem is that there are so many ways you might want to use an
object as a function, not just one. In this case, we want it as a
predicate. In other cases you might want it to return the match as a
string, or as a match. Or you want your generic objects to match
again
On Mar 24, 2012, at 7:28 AM, David Herman wrote:
> On Mar 21, 2012, at 9:13 AM, Allen Wirfs-Brock wrote:
>
>> On Mar 20, 2012, at 11:32 PM, David Herman wrote:
>>
>>> Well, hang on now. The 'constructor' syntax is not "just the constructor
>>> property." It still carries special status; the se
Thanks for the detailed comments! Replies below.
Norbert
On Mar 23, 2012, at 9:46 , Phillips, Addison wrote:
> Comments follow.
>
> 1. Definition of string. You say:
>
> --
> However,
>ECMAScript does not place any restrictions or requirements on the sequence
>of code units in a Strin
On Mar 23, 2012, at 7:12 , Lasse Reichstein wrote:
> On Fri, Mar 23, 2012 at 2:30 PM, Steven Levithan
> wrote:
>> I've been wondering whether it might be best for the /u flag to do three
>> things at once, making it an all-around "support Unicode better" flag:
>
> ...
>
>> 3. [New proposal] Ma
On Mar 23, 2012, at 6:30 , Steven Levithan wrote:
> Norbert Lindenberg wrote:
>
>> I've updated the proposal based on the feedback received so far. Changes
>> are listed in the Updates section.
>> http://norbertlindenberg.com/2012/03/ecmascript-supplementary-characters/
>
> Cool.
>
> From the
On Mar 24, 2012, at 3:01 PM, Nadav Shesek wrote:
> What about setting arbitrary expressions as the value for prototype methods?
> Being able to use higher-order functions to dynamically create functions is
> very important for functional style programming. I use it very often to
> decorate func
What about setting arbitrary expressions as the value for prototype
methods? Being able to use higher-order functions to dynamically create
functions is very important for functional style programming. I use it very
often to decorate functions, compose functions together, set partially
applied func
This isn't a huge "Ask" to use your term, but it's also not a big win.
We can talk about it off-agenda at next week's meeting, try to get a
feel for odds of adding it. I'll bring it up. Thanks,
/be
Roger Andrews wrote:
Perhaps I spoke a little too loosely there.
The hexadecimal exponential fo
Andreas Rossberg wrote:
(OTOH, I'd prefer finding a way to do guards with single ':'... :-) )
I started there too (ES4, ML which was used [SML] for the ES4 reference
implementation, other work such as Links). But TC39 argued about it and
the desire to guard property names in object literals l
On 24 March 2012 17:22, David Herman wrote:
>
> I'm not 100% clear on this point yet, but e.g. the SourceCharacter
> production in Annex A.1 is described as "any Unicode code unit."
>
Ugh, IMHO, that's wrong, and should be "any Unicode code point". (let the
flames begin?)
> The underlying trans
On Mar 24, 2012, at 1:11 PM, Wes Garland wrote:
> On 24 March 2012 15:25, David Herman wrote:
> > Presumably the JS source, as a sequence of UTF-16 code units, represents
> > the tetragram code points as surrogate pairs.
>
> Clarification: the JS source *of the regexp literal*.
>
>
> We certa
(function () {}) creates two object, not one.
I'm not sure what you meant here. ..
the empty object for the function's .prototype
currently seems to elude me in all its forms..
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.m
On 24 March 2012 15:25, David Herman wrote:
> > Presumably the JS source, as a sequence of UTF-16 code units, represents
> the tetragram code points as surrogate pairs.
>
> Clarification: the JS source *of the regexp literal*.
>
>
We certainly can, although this means that certain Unicode Strings
> Presumably the JS source, as a sequence of UTF-16 code units, represents the
> tetragram code points as surrogate pairs.
Clarification: the JS source *of the regexp literal*.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozil
On Mar 23, 2012, at 6:30 AM, Steven Levithan wrote:
> I've been wondering whether it might be best for the /u flag to do three
> things at once, making it an all-around "support Unicode better" flag:
+all my internet points
Now you're talking!!
> 1. Switches from code unit to code point mode.
On Mar 23, 2012, at 11:45 AM, Roger Andrews wrote:
> Concerning UTF-16 surrogate pairs, how about a function like:
> String.isValid( str )
> to discover whether surrogates are used correctly in 'str'?
>
> Something like Array.isArray().
No need for it to be a class method, since it only ope
This seems special purpose enough (as you say, for legacy formats) and easy
enough to implement, that it probably doesn't warrant being included in the
language.
- Russ
On Mar 23, 2012, at 5:36 PM, "Roger Andrews"
wrote:
> String.prototype.split is good for cutting records into fields based
String.prototype.split is good for cutting records into fields based on a
delimiter string or regexp. E.g.
rec.split( ',' ) // split CSV record (no commas in fields)
rec.split( /\s+/ ) // split into whitespace-separated fields
How about extending 'split', or inventing
On Mar 21, 2012, at 9:13 AM, Allen Wirfs-Brock wrote:
> On Mar 20, 2012, at 11:32 PM, David Herman wrote:
>
>> Well, hang on now. The 'constructor' syntax is not "just the constructor
>> property." It still carries special status; the semantics of a class says
>> "look for the property called '
On 23 March 2012 21:59, Irakli Gozalishvili wrote:
>
> A. ./foo.js ../foo/bar.js
> B. foo.js, foo/bar.js
>
> I'd suggest to resolve A type paths relative to a requirer (ether require
> module url, or document url). And resolve B
> type paths relative to a `document.baseURI`.
>
This is almost wha
On Mar 23, 2012, at 1:17 PM, Brendan Eich wrote:
> class Point extends Evil {
>constructor(ax, ay) {
> public x, y;
>super();
> this.x = ax;
> this.y = ay;
>}
>...
> }
>
> class Evil {
>constructor() {
> console.log(this.x);
>}
> }
>
> Should un
Somehow, this did not get into the list, so I am resending it...
hopefully it won't get duplicated.
Original Message
From: Herby Vojčík
Subject: Setting inheritance chains, <|, extends, class and all the stuff
Date: Wed, 21 Mar 2012 18:58:59 +0100
To: ECMAScript discussion
H
On Sat, Mar 24, 2012 at 5:54 AM, Brandon Benvie
wrote:
> I've been struggling for a way to describe this idea, but it's almost like
> we're lacking what amounts to a "valueOf" where the expected result is a
> callable. The regex-as-filter is a good example of that use case. You don't
> want the ba
Neither. Currently, <| sets the [[prototype]] field of the RHS object,
and -if the RHS is a function literal- also specifies the [[prototype]]
field of objects generated from it. I suggest to remove that special
case for function RHS.
(function () {}) creates two object, not one.
I'm not sure
Brendan Eich wrote:
js> ["fOo","bAr"].filter(function(){return /foo/i});
["fOo", "bAr"]
LOL, I returned a truthy value. Fixing:
js> ["fOo","bAr"].filter(function(s){return /foo/i.test(s)});
["fOo"]
Even longer :-/.
So yes, callable regexps were useful -- that's why I made 'em callable
way
34 matches
Mail list logo
