Re: More fun with undefined
On 15 June 2012 07:42, Herby Vojčík he...@mailbox.sk wrote: T.J. Crowder wrote: Making a point of making this a separate thread from the current ?? and ??= thread(s), which are thankfully looking close to consensus. So that's infix and assignment. Question: Should we consider unary as well? I also thought in these lines. What I came up is this: (foo??) // (foo !== undefined) foo??bar// (foo !== undefined) ? foo : bar aka foo ?? foo : bar that is, allow ?? also without the operand, but then only at the end of (sub)expression Again, let's consider whether the semantics are worth it before we get into synxtax. I take it you're in favor of something? P.S.: foo??bar:baz wouldn't hurt either, to complete the triad. I've suggested that a couple of times.[1][2] Brendan said he thought it was too thin.[3] AFAIK no one else has weighed in on the subject. [1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023356.html [2] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023465.html [3] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023468.html -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 15 June 2012 01:22, Allen Wirfs-Brock al...@wirfs-brock.com wrote: A wonder if this wart is hairy enough, that we wouldn't be justified in some explicit backwards compatibility hackery in the spec. to remove it. For example, we could allow it to appear in parameter lists and provide a dynamic check to ensure that nothing (other than a real undefined) is passed. Similarly we could explicitly allow: var undefined; Actually, for very much the same effect, you could simply treat 'undefined' as a (refutable) _pattern_ that is only matched by the undefined value. No need to make special rules for var or parameters then. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
T.J. Crowder wrote:
On 15 June 2012 07:42, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
T.J. Crowder wrote:
Making a point of making this a separate thread from the current
?? and
??= thread(s), which are thankfully looking close to consensus. So
that's infix and assignment.
Question: Should we consider unary as well?
I also thought in these lines. What I came up is this:
(foo??) // (foo !== undefined)
foo??bar// (foo !== undefined) ? foo : bar aka foo ?? foo : bar
that is, allow ?? also without the operand, but then only at the end
of (sub)expression
Again, let's consider whether the semantics are worth it before we get
into synxtax. I take it you're in favor of something?
Well, now that I think about it... whatever. I can live with both.
Though trueish !== undefined seems more natural to me (especially
inside if).
If the new syntax is clear that it's otherwise, it can be === undefined,
as well.
For example if (isnt foo) {...} (but this immediately suggest there can
be unary is as well... which is nice, there could be both).
P.S.: foo??bar:baz wouldn't hurt either, to complete the triad.
I've suggested that a couple of times.[1][2] Brendan said he thought it
was too thin.[3] AFAIK no one else has weighed in on the subject.
I know, I just sort-of included it to show I like it.
[1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023356.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023465.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023468.html
-- T.J.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 15 June 2012 08:09, Andreas Rossberg rossb...@google.com wrote: On 15 June 2012 01:22, Allen Wirfs-Brock al...@wirfs-brock.com wrote: A wonder if this wart is hairy enough, that we wouldn't be justified in some explicit backwards compatibility hackery in the spec. to remove it. For example, we could allow it to appear in parameter lists and provide a dynamic check to ensure that nothing (other than a real undefined) is passed. Similarly we could explicitly allow: var undefined; Actually, for very much the same effect, you could simply treat 'undefined' as a (refutable) _pattern_ that is only matched by the undefined value. No need to make special rules for var or parameters then. Folks, could we move the unrelated discussion to its own thread? This thread's original subject is rather getting lost here. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Yes, what I mean is that I did not see since a long time something like a===null?b:c or if (a===null)||b, and except for specific use like Object.create(null) I don't see a lot of null being used, then making the distinction for ??, ?: and others looks too subtle Le 15/06/2012 04:20, Brendan Eich a écrit : On Jun 14, 2012, at 6:38 PM, Aymeric Vittevitteayme...@gmail.com wrote: Maybe I missed it, never saw the use of null since a long time, but I can be wrong As Allen pointed out, null is specified in ECMA-262, e.g. Object.getPrototypeOf. /be -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
This isn't unrelated. If we do get patterns into Harmony they may subsume some of the postfix-?? (which does not work syntactically, IMHO) or prefix-? ideas. Or at least prefix-? may show up in the pattern language (dherman and I have discussed it). Syntax design requries global oversight, there are cross-cutting concerns and different complexity budgets to bean-count (but never too locally or blindly). /be T.J. Crowder wrote: On 15 June 2012 08:09, Andreas Rossberg rossb...@google.com mailto:rossb...@google.com wrote: On 15 June 2012 01:22, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: A wonder if this wart is hairy enough, that we wouldn't be justified in some explicit backwards compatibility hackery in the spec. to remove it. For example, we could allow it to appear in parameter lists and provide a dynamic check to ensure that nothing (other than a real undefined) is passed. Similarly we could explicitly allow: var undefined; Actually, for very much the same effect, you could simply treat 'undefined' as a (refutable) _pattern_ that is only matched by the undefined value. No need to make special rules for var or parameters then. Folks, could we move the unrelated discussion to its own thread? This thread's original subject is rather getting lost here. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 15 June 2012 12:41, Brendan Eich bren...@mozilla.com wrote: This isn't unrelated. If we do get patterns into Harmony they may subsume some of the postfix-?? (which does not work syntactically, IMHO) or prefix-? ideas. Or at least prefix-? may show up in the pattern language (dherman and I have discussed it). I was talking about the discussion around making undefined non-redefinable. Of the first 6 responses, one was about the original subject (having a unary version of ??), the others were about whether undefined should be redefinable. Different (and potentially useful) topic, in my view. Allen even opened with This is a different issue, but... -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
I think the original thrust of this thread may have got lost a bit in the (useful) discussion of null and undefined, so coming back to the original point: On 12 June 2012 16:29, T.J. Crowder t...@crowdersoftware.com wrote: In the current default operator strawman[1], the operator is ??, e.g.: a = b ?? 5; is shorthand for a = b !== undefined ? b : 5; Would it be possible to use ||| instead? E.g.: a = b ||| 5; I ask because I was planning (prior to knowing about this strawman!) to suggest that, along with a different form of ?? (or ???) which introduces a new ternary operator: a = b ?? 5 : 6; ...which would be a shorthand form of a = b !== undefined ? 5 : 6; [1] http://wiki.ecmascript.org/doku.php?id=strawman:default_operator Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't _need_ it), Brendan's (too thin)[1], and Herby's (wouldn't hurt)[2]. (Speaking syntactically, I think we all agreed in the other thread that ||| [above] won't work for the infix, because the assignment form just becomes too confusing, as Wes pointed out.[3]) [1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023468.html [2] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023510.html [3] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023386.html -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
Probably there are very good reasons but I reask the question : why
should the attempt to access a property of a variable equal to undefined
global property not return undefined global property ? (ie a way that
this works : if (a.b.c.d) {} when a,a.b, etc are not set)
This can be usefull when things get loaded asynchronously and then when
you don't know when it will be available (it does not happen every day,
but in some cases you don't have necessarily a callback or an event to
tell you and then asynchronous stuff can start being extremely difficult
to handle).
Example :
console.log(a);//Reference error, GetBase returns undefined
console.log(window.a);//undefined
-- does not seem very logical, no ?
Maybe it was discussed thousand of times, but why not :
8.9.1 GetValue (V)
...
5. If IsUnresolvableReference(V), return undefined
Le 15/06/2012 01:22, Allen Wirfs-Brock a écrit :
On Jun 14, 2012, at 3:49 PM, Rick Waldron wrote:
On Thu, Jun 14, 2012 at 5:35 PM, Thaddee Tyl thaddee@gmail.com
mailto:thaddee@gmail.com wrote:
On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
This is a different issue, but I wonder how badly the web would
break if we
made undefined a reserved word. Does anybody in JS really
declare a
different local binding for undefined? In ES5 we got away with
making
undefined read-only. Maybe we should continue pushing and see
if we can
eliminate the rebindable undefined hazard.
JQuery [1] famously has an undefined parameter, like so:
(function( window, undefined ) { ... }(window))
Actually, this exists because undefined wasn't reserved. We would
certainly remove the formal param in favor of an reserved undefined.
Unfortunately, we can't take it back in extant code.
A wonder if this wart is hairy enough, that we wouldn't be justified
in some explicit backwards compatibility hackery in the spec. to
remove it.
For example, we could allow it to appear in parameter lists and
provide a dynamic check to ensure that nothing (other than a real
undefined) is passed. Similarly we could explicitly allow:
var undefined;
Certainly there is no particular reasons we need to allow:
let undefined;
const undefined=true;
class undefined extends foo { }
or any other new binding forms redefining undefined.
Allen
Rick
What would happen in this case?
[1] http://code.jquery.com/jquery-1.7.2.js
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 15 June 2012 14:34, Aymeric Vitte vitteayme...@gmail.com wrote:
Example :
console.log(a);//Reference error, GetBase returns undefined
console.log(window.a);//undefined
-- does not seem very logical, no ?
To me this would be a big step backward, after the very large stride
forward this group made in ES's strict mode of making _assigning_ to an
unresolvable reference an error rather than an implicit creation of a
property on the global object.
For one thing, how is the engine to know that the `a` in question was meant
to be `window.a`? Maybe I just forgot to put `var a` in the current scope.
(In fact, that's usually what it is when I get this error.)
Scope is not the same as an object (although of course, the scope chain is
conceptually made up of binding objects). If I refer to `a` in my code and
`a` has never been declared, that's a bug, and as I haven't told it, the
engine has no way of knowing what level in the scope chain I intended `a`
to be in. If I access the `a` property of an object, and the property has
never been defined, that could just be lazy initialization; the engine
knows that I'm talking about that specific object (or its prototypes),
because I've told it what object to look at.
Separately:
(ie a way that this works : if (a.b.c.d) {} when a,a.b, etc are not set)
Making the initial `a` evaluate to `undefined` wouldn't make that work:
Instead of the ReferenceError, you'd get a TypeError (cannot read property
`b` of undefined).
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
I am not talking about defining implicit properties or such things,
neither having undeclared stuff looking declared, but just changing the
behavior of retrieving a property when base is undefined, which will
then be undefined.
If am I reading correctly the specs, doing this change will work for
a.b.c.d, because undefined is returned first and nothing is set
anywhere, unless I am wrong :
console.log(a); //reference error
var a;//undefined
console.log(a.b);//reference error
will become :
console.log(a); //undefined
var a;//undefined
console.log(a.b);//undefined
Le 15/06/2012 15:52, T.J. Crowder a écrit :
On 15 June 2012 14:34, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Example :
console.log(a);//Reference error, GetBase returns undefined
console.log(window.a);//undefined
-- does not seem very logical, no ?
To me this would be a big step backward, after the very large stride
forward this group made in ES's strict mode of making _assigning_ to
an unresolvable reference an error rather than an implicit creation of
a property on the global object.
For one thing, how is the engine to know that the `a` in question was
meant to be `window.a`? Maybe I just forgot to put `var a` in the
current scope. (In fact, that's usually what it is when I get this error.)
Scope is not the same as an object (although of course, the scope
chain is conceptually made up of binding objects). If I refer to `a`
in my code and `a` has never been declared, that's a bug, and as I
haven't told it, the engine has no way of knowing what level in the
scope chain I intended `a` to be in. If I access the `a` property of
an object, and the property has never been defined, that could just be
lazy initialization; the engine knows that I'm talking about that
specific object (or its prototypes), because I've told it what object
to look at.
Separately:
(ie a way that this works : if (a.b.c.d) {} when a,a.b, etc are
not set)
Making the initial `a` evaluate to `undefined` wouldn't make that
work: Instead of the ReferenceError, you'd get a TypeError (cannot
read property `b` of undefined).
-- T.J.
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 15 June 2012 15:34, Aymeric Vitte vitteayme...@gmail.com wrote:
I am not talking about defining implicit properties or such things,
neither having undeclared stuff looking declared, but just changing the
behavior of retrieving a property when base is undefined, which will then
be undefined.
If am I reading correctly the specs, doing this change will work for
a.b.c.d, because undefined is returned first and nothing is set anywhere,
unless I am wrong :
console.log(a); //reference error
var a;//undefined
console.log(a.b);//reference error
will become :
console.log(a); //undefined
var a;//undefined
console.log(a.b);//undefined
So you're proposing two changes:
1. Let getting an unresolvable symbol evaluate to `undefined`, rather than
causing a ReferenceError (which requires changing GetValue, at least), and
2. Allow accessing a property of `undefined` to evaluate to `undefined`,
rather than causing a TypeError (which requires changing either how
property accessors work, or changing the definition of CheckObjectCoercible
so that it coerces undefined into {} or some such).
You'd need both of them to make `a.b` work (evaluate to undefined rather
than throwing) where `a` is unresolvable, #1 to prevent the ReferenceError
on `a`, and #2 to prevent the TypeError when trying to retrieve `b` from
`undefined`.
Either would be a big, breaking change on its own.
Re #1: I wouldn't be in favor, FWIW. I think it's much better to have a
ReferenceError on an unresolvable symbol than have it treated as though it
were resolved, but had the value `undefined`. Again, the feature of strict
mode where assigning to unresolvable symbols stopped creating global
variables was a Good Thing(tm). :-) To me this is in the same vein as the
old behavior there was. If I try to read the value of an unresolvable
symbol, I want the proactive notification I get from the ReferenceError; I
don't want to try to find the subtle bug the implicit `undefined` helps
hide (in my view).
Re #2: I wouldn't be in favor, FWIW. Consider:
function foo(o) {
console.log(o.msg);
}
foo();
Currently, the call to `foo` throws, because I'm not passing in any
argument, but the code dereferences `o` without testing first. This is
clearly a bug in the call to `foo`. Currently, I get proactive notification
of that bug (via the TypeError). With change #2, the code would try to log
undefined instead -- a much harder, more subtle bug to try to find and fix.
Yes, the current behavior wrt reading from unresolvable references vs.
reading from undefined properties can be viewed, from some angles, as
inconsistent. But it's very thoroughly ingrained in the language, and I
don't see a strong argument for change.
Just my $0.02.
Best,
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape()
On 23 March 2012 12:12, Steven Levithan wrote: Erik Corry wrote: In perl the recommended version is text.replace(/([^a-zA-Z0-9])/g, \\$1) which is future-proof and safe and I think this also works for JS. It's probably future-proof and safe, but it escapes 65,520 characters more than necessary. Anyway, no big deal if this isn't added. I have, however, seen a lot of developers get this wrong when trying to do it themselves (e.g., the blog post that started this thread was not safe until it was updated 4+ years later, and it wasn't the worst I've seen). I've seen at least three that missed things out as well. The all but alnums approach doesn't seem to occur to people. On 23 March 2012 12:37, Steven Levithan wrote: Erik Corry wrote: In perl the recommended version is text.replace(/([^a-zA-Z0-9])/g, \\$1) For the record, most languages with modern regular expressions include a built in method for this. For instance: * Perl: quotemeta(str) * PHP: preg_quote(str) * Python: re.escape(str) * Ruby: Regexp.escape(str) * Java: Pattern.quote(str) * C#, VB.NET: Regex.Escape(str) Indeed. +1 for RegExp.escape in ES. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: [[strawman:data_parallelism]] |this| and fat arrows
Hey Mark,
ParallelArray and index are left out because of our desire to provide a few
good methods that help/force programmers to think about parallel algorithms and
not just speeding up sequential algorithms. Array map is really just syntactic
sugar for for loops and invites thinking that depends on order. For
ParallelArray map we felt that the value was the semantically important thing
and the user should not be distracted by the index. Not having index available
is one step towards thinking in more parallel ways.
In situations where index is more semantically important than the value we
provide the method combine. Here we pass the ParallelArray and the index and
not the value to the kernel function. A blur function that averages the values
surrounding some location would naturally use combine. The documentation
encourages the programmer to think of index as the _destination_ of the value
the kernel function returns. Again the intent is to try and break away from
sequential thinking.
Filter is like combine, it gets the ParallelArray and the index and allows
filtering based on location. If one accepts the above map/combine arguments
then one could make a reasonable argument that there should be a filter based
on value and a filter based on location. (Thanks you've forced me to think
about this again.)
The other methods have less use for index.
Reduce) we agree that passing in the index doesn't make sense.
Scan) has the same problems with index that reduce has.
Scatter) takes an array of destination indices and a 2 arg conflict function.
The index of both of the source elements isn't always available so it doesn't
make sense here either.
Not passing in the ParallelArray was a tougher decision. We really liked the
way we had |this| bound to the ParallelArray since it made composition / nested
parallelism straight forward and natural. With the exception of combine and
filter the programmer has to arrange for the ParallelArray to be available in
order to do composition.
I think a clean break from high order Array methods is the way to go here,
syntactically similar forms with semantically different meaning is worth
avoiding.
- Rick
Guy Steele Language design is as much the art of what to leave out as what to
put in.
-Original Message-
From: Mark S. Miller [mailto:erig...@google.com]
Sent: Thursday, June 14, 2012 7:32 PM
To: Hudson, Rick
Cc: es-discuss
Subject: Re: [[strawman:data_parallelism]] |this| and fat arrows
Hi Rick,
Even without =, I think this is an improvement to the API overall, as
it makes it more similar to the corresponding array methods. However,
I do not see the problem with making it much more similar. I agree
regarding reduce and reduceRight, but fortunately, these already
violate the general pattern for the other higher order array methods
-- in that they call their callbackfn with this always bound to
undefined. In retrospect, I wish we had called the existing function
reduceLeft so yours could be called simply reduce and have the
name difference suggest the lack of order.
Regarding the others, the general pattern from the ho array methods is
array.foo(callbackfn, possible-other-args, optional-this-arg)
calls back
callbackfn(value, index, array, this-arg-or-undefined)
I wish that the optional-this-arg had been omitted from ES5, but for
the sake of compat with the Prototype library and other
implementations of these methods, I lost that argument. In retrospect
I agree with that decision, even though I still believe that the
this-arg has net negative value. By the same reasoning, I think you
should follow this pattern as well except when there's a good argument
not to. For reduce you make a good argument.
Further comments inline below.
On Fri, Jun 15, 2012 at 4:27 AM, Hudson, Rick rick.hud...@intel.com wrote:
Proposed change to [[strawman:data_parallelism]]
The ParallelArray methods map, combine, reduce, scan, scatter, and filter,
each take a kernel function as an argument. Within this kernel function
|this| is currently bound to the ParallelArray. This was natural and
non-controversial
I disagree that it was non-controversial -- I argued against it on
compat grounds at the time. But I agree with your point that = makes
that old design even less viable.
as long as we used the function(){..} form which did not
restrict how |this| was bound and explaining the semantics in terms of call
or apply was perfectly reasonable. = is likely to change that. =, as
proposed, enforces a lexical |this| and is semantically different than the
function () {..} form. Going forward we expect folks to use the = form more
than the function form. For the most part we will be leaving the kernel
signatures as they are except that we will no longer bind |this| to the
ParalleArray is inside a kernel function. Instead |this| will be bound in
accordance to existing JavaScript specifications and
[[strawman:data_parallelism]] will no
Re: RegExp.escape()
YES. PLEASE put this in!
http://stackoverflow.com/a/6969486/151312
function escapeRegExp(str) {
return str.replace(/[\-\[\]\/\{\}\(\)\*\+\?\.\\\^\$\|]/g, \\$);
}
I'm doing my best to reply to every single question that pops up on
stackoverflow and point them to this answer... but there are just too many
wrong answers out there.
AJ ONeal
On Fri, Jun 15, 2012 at 9:17 AM, T.J. Crowder t...@crowdersoftware.comwrote:
On 23 March 2012 12:12, Steven Levithan wrote:
Erik Corry wrote:
In perl the recommended version is
text.replace(/([^a-zA-Z0-9])/g, \\$1)
which is future-proof and safe and I think this also works for JS.
It's probably future-proof and safe, but it escapes 65,520 characters
more
than necessary.
Anyway, no big deal if this isn't added. I have, however, seen a lot of
developers get this wrong when trying to do it themselves (e.g., the blog
post that started this thread was not safe until it was updated 4+ years
later, and it wasn't the worst I've seen).
I've seen at least three that missed things out as well. The all but
alnums approach doesn't seem to occur to people.
On 23 March 2012 12:37, Steven Levithan wrote:
Erik Corry wrote:
In perl the recommended version is
text.replace(/([^a-zA-Z0-9])/g, \\$1)
For the record, most languages with modern regular expressions include a
built in method for this.
For instance:
* Perl: quotemeta(str)
* PHP: preg_quote(str)
* Python: re.escape(str)
* Ruby: Regexp.escape(str)
* Java: Pattern.quote(str)
* C#, VB.NET: Regex.Escape(str)
Indeed. +1 for RegExp.escape in ES.
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More fun with undefined
On 15 June 2012 17:00, Aymeric Vitte vitteayme...@gmail.com wrote: Right now I am not proposing but trying to understand why it is like this Sorry, I thought you were proposing something. Your first message talked about changing how GetValue works, apologies if I misunderstood. Brendan could speak FAR better to why than I can. I would expect it's because, as I said earlier, scope and identifier resolution is just plain _different_ from objects and property resolution. Maybe they didn't have to be different, but they are, and always has been. Attempts to conflate the two (the `with` structure, for instance, which intermixes an object's properties with scope resolution) have been unsuccessful and are now seen to be...not the best way forward. ...and if by any chance a.b.c.d could be solved If you want to get `a.b.c.d` but you aren't sure whether `a` is resolvable, you can do this: var v = typeof a === object typeof a.b === object typeof a.b.c === object a.b.c.d; `v` will end up with either `undefined` or the value of `a.b.c.d`. Taking the type of an unresolvable identifier doesn't cause a ReferenceError. Indeed this would require an early return from Accessors too after GetValue(base) . I don't understand why you focus on global var being created, this is not the case. I wasn't trying to say your change to GetValue resulted in creating globals. I'm just pointing out the similarity of issues between your proposed behavior (using an implicit `undefined` when faced with getting an unresolvable identifier) and that previous behavior (creating a global when *putting* to an unresolvable identifier). The previous behavior was sufficiently problematic that ES moved _away_ from doing this sort of implicit stuff _toward_ using ReferenceError more consistently (e.g., on put as well as get, in strict mode). Maybe I am misreading something in the chain, the Accessors CheckObjectCoercible and GetValue IsUnresolvableReference look to be redundant in this case. var a; console.log(a.b); //TypeError for you (correct ?)- Reference error for me console.log(c.d);//Reference error for me With the `var a;` there, my understanding is `console.log(a.b)` should raise a TypeError, and that's what I get from V8.[1] (Be sure you have the console open when opening that.) *Without* the `var a;` declaration, it should raise a ReferenceError. Why: *With* the `var a;` there, `a` is `undefined` (not unresolvable), so for the `a.b` expression, the property accessor operation[2] gets the base (steps 1 and 2), which will be `undefined`, and the property name (steps 3 and 4), which will be b. Step 5 is to call CheckObjectCoercible[3] passing in the base, which is `undefined`. CheckObjectCoercible throws a TypeError if given `undefined`. *Without* the `var a;`, `a` is unresolvable and so before we even get to the property accessor, we've already run into the ReferenceError from GetValue (which you highlighted in your original message). Regardless of why, I for one am happy that reading from (and now in strict mode writing to) unresolvable identifiers results in a ReferenceError. I get nice proactive notification when I forget to declare things. :-) [1] http://jsbin.com/ufezog [2] http://ecma-international.org/ecma-262/5.1/#sec-11.2.1 [3] http://ecma-international.org/ecma-262/5.1/#sec-9.10 -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Fri, Jun 15, 2012 at 6:28 AM, T.J. Crowder t...@crowdersoftware.com wrote: Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't _need_ it), Brendan's (too thin)[1], and Herby's (wouldn't hurt)[2]. Since you are asking for opinions. I don't want it. It doesn't carry its own weight. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On 15 June 2012 18:05, Erik Arvidsson erik.arvids...@gmail.com wrote: Since you are asking for opinions. I don't want it. It doesn't carry its own weight. I was, and that includes opinions against. Thanks! -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape()
On Mar 23, 2012, at 8:16 AM, Steven Levithan wrote:
Although this is only a minor convenience since you can do something like
text.replace(/[-[\]{}()*+?.,\\^$|]/g, \\$), the list of special characters
is subject to change.
That sounds like another good argument for standardizing.
The only challenge I see is how to fudge the spec enough to mandate that any
extended, non-standard operators that the engine provides should also be
escaped.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Protected properties using Name objects
Currently there's no way to have a data property that is writable by some
but not all. This can't even really be achieved with accessors or proxies
directly. Rather, the underlying data is mutated through some other avenue,
and the value returned on access comes from this secondary source. Neither
method of course is remotely as efficient as a real data property as either.
Using Name objects, it seems like a full fledged elegant protected
property access API is possible to describe. For this context, I define a
protected property as a property on an object who's description or value
can only be modified after passing some access check. There's two levels of
access covered by what I propose: the base level ability to write a
property's data (`writable` descriptor property) and the ability to
configure a property (`configurability` descriptor property).
For writing to an object, this concept allows for a property to be {
writable: false } but be written through a Name object corresponding to the
property.
For modifying the property's descriptor, a fourth boolean descriptor
attribute is now defined named 'protected'. When a property is protected,
the Name object associated with it is required in order to modify it using
Object.defineProperty. A property which is protected acts the same as a
non-configurable property when modification is attempted using the
property's string name. A property can become unprotected later, unlike a
non-configurable property, and can be modified internally to engine as
well. Protected only acts like non-configurable for unauthorized access
from code.
Code (also available at https://gist.github.com/2938186)
let x = { a: 10 };
// #
// ### Protecting a property ###
// #
let writeA = Object.protectProperty(x, 'a');
// -- or --
let writeA = new Name;
Object.protectProperty(x, 'a', writeA);
// ###
// ### Describing a protected property ###
// ###
Object.isProtected(x, 'a');
// true
Object.getOwnPropertyDescriptor(x, 'a')
// { writable: false, default protectProperty to set non-writable?
//protected: true,
//enumerable: true,
//configurable: true }
// #
// ### Writing to protected property ###
// #
x.a = 50
// silent fail normally, throws in strict Cannot assign to protected
read-only property 'x'
x[writeA] = 50;
// x is { a: 50 }
// ##
// ### Modifying a protected property description ###
// ##
Object.defineProperty(x, 'a', { writable: true });
// throw Cannot modify protected property 'a'
Object.defineProperty(x, writeA, { writable: true });
// { writable: true,
//protected: true,
//enumerable: true,
//configurable: true }
// ###
// ### Unprotecting a property ###
// ###
Object.defineProperty(x, writeA, { protected: false });
// -- or --
Object.protectProperty(x, writeA);
// #
// ### Changing a protected property key ###
// #
Object.defineProperty(x, writeA, { protected: false });
let newWriteA = Object.protectProperty(x, 'a');
// -- or --
let newWriteA = new Name();
Object.protectProperty(x, writeA, newWriteA);
x[writeA] = 100;
// throw 'Invalid protected property assignment'
// from
http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
const pHealth = new Name();
const wAlive = new Name();
class Monster {
constructor(name, health) {
this.name = name;
this.alive = true;
this[pHealth] = health;
Object.protectProperty(this, 'alive', wAlive);
}
attack(target) {
log('The monster attacks ' + target);
}
defend(roll) {
let damage = Math.random() * roll;
this[pHealth] -= damage;
if (this[pHealth] = 0) {
this[wAlive] = false;
}
}
set health(value) {
if (value 0) {
throw new Error('Health must be non-negative.');
}
this[pHealth] = value;
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 14, 2012, at 1:45 PM, Brendan Eich wrote: I can see adding ?? and ??= (undefined-only, not undefined-or-null). I think ?? is the highest priority. Is ||= really worth it? It would not assign if the left side is truthy, but perhaps no one will mind. Given ||= is there any oxygen left in the room for ??=? ??= is strictly less error-prone than ||= so I can't see why we would favor ||= if we were choosing just one. As I see it, the biggest issue with ??= and ||= is that -- unlike other compound assignment forms -- they are short-circuiting. All the existing compound assignment forms evaluate both sides no matter what. IIRC, back in the ES4 days, this is why we rejected ||=. I'm still not against it, though. It's obvious what it means. It's obviously useful. So I favor ?? as well as both ||= and ??=. As for null, I can see how there's confusion about whether to use null vs undefined, and so I can see why CoffeeScript would just try to blur the distinction between them. But I think by sticking to the simpler semantics it will help clarify the distinction. The JS semantics currently treats only undefined as no value and it would continue to do so. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
David Herman wrote: So I favor ?? as well as both ||= and ??=. As for null, I can see how there's confusion about whether to use null vs undefined, and so I can see why CoffeeScript would just try to blur the distinction between them. But I think by sticking to the simpler semantics it will help clarify the distinction. The JS semantics currently treats only undefined as no value and it would continue to do so. I agree on all this. I'll update the strawman soon. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
The description of Object.protectProperty: Object.protectProperty(object : Object, key : String) - Name Object.protectProperty(object : Object, key : String, protector : Name) - true Object.protectProperty(object : Object, currentProtector : Name) - true Object.protectProperty(object : Object, currentProtector : Name, newProtector : Name) - true [object, key] returns new Name to be used as protector [object, key, protector] sets protector to existing Name [object, currentProtector] sets protected to false [object, currentProtector, newProtector] change protector to newProtector ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
Hi.
I have hard time to put my objections well. Different words appear in my
mind like too monolithic, too spaghetti, ... but none of them is
very good at explaining the problem.
It seems to me that this make thing complex and brittle. Protected
overides writable and configurable, so their meaning is compromised.
Having fourth one added to the three increases the number of
combinations. Having only one or none protected key brings problems with
later unprotecting / reprotecting when there are more than one subset of
consumers.
I include a counter-proposal, which defines aliases for existing
properties, albeit with different access.
Brandon Benvie wrote:
Currently there's no way to have a data property that is writable by
some but not all. This can't even really be achieved with accessors or
proxies directly. Rather, the underlying data is mutated through some
other avenue, and the value returned on access comes from this secondary
source. Neither method of course is remotely as efficient as a real data
property as either.
Using Name objects, it seems like a full fledged elegant protected
property access API is possible to describe. For this context, I define
a protected property as a property on an object who's description or
value can only be modified after passing some access check. There's two
levels of access covered by what I propose: the base level ability to
write a property's data (`writable` descriptor property) and the ability
to configure a property (`configurability` descriptor property).
For writing to an object, this concept allows for a property to be {
writable: false } but be written through a Name object corresponding to
the property.
For modifying the property's descriptor, a fourth boolean descriptor
attribute is now defined named 'protected'. When a property is
protected, the Name object associated with it is required in order to
modify it using Object.defineProperty. A property which is protected
acts the same as a non-configurable property when modification is
attempted using the property's string name. A property can become
unprotected later, unlike a non-configurable property, and can be
modified internally to engine as well. Protected only acts like
non-configurable for unauthorized access from code.
Code (also available at https://gist.github.com/2938186)
let x = { a: 10 };
// #
// ### Protecting a property ###
// #
let writeA = Object.protectProperty(x, 'a');
let writeA = Object.aliasProperty(x, 'a', { enumerable: true,
configurable: true, writable: true});
// -- or --
let writeA = new Name;
Object.protectProperty(x, 'a', writeA);
let writeA = new Name;
Object.aliasProperty(x, 'a', writeA, { enumerable: true, configurable:
true, writable: true}); // or writeA as last
// ###
// ### Describing a protected property ###
// ###
Object.isProtected(x, 'a');
// true
N/A, not needed. Instead maybe this, if needed:
Object.isAlias(x, 'a')
// false
Object.isAlias(x, writeA);
// true
Object.getOwnPropertyDescriptor(x, 'a')
// { writable: false, default protectProperty to set non-writable?
//protected: true,
//enumerable: true,
//configurable: true }
returns present state of property 'a' as usual. It can have false anywhere.
// #
// ### Writing to protected property ###
// #
x.a = 50
// silent fail normally, throws in strict Cannot assign to protected
read-only property 'x'
// behaves as normal proerty (fails silently or not if non-writable)
x[writeA] = 50;
// x is { a: 50 }
// ##
// ### Modifying a protected property description ###
// ##
Object.defineProperty(x, 'a', { writable: true });
// throw Cannot modify protected property 'a'
// again, behaves normally, fails if nonconfigurable.
Object.defineProperty(x, writeA, { writable: true });
// { writable: true,
//protected: true,
//enumerable: true,
//configurable: true }
// behaves normally like on 'a' except it has access of writeA.
// So if it 'a' was non-writable, configurable and enumerable, returns:
// { writable: true,
// enumerable: true.
// configurable: true }
// ###
// ### Unprotecting a property ###
// ###
Object.defineProperty(x, writeA, { protected: false });
// -- or --
Object.protectProperty(x, writeA);
Object.removeAlias(x, writeA);
// true
// removes writeA alias
// It is different than delete x.writeA, which
// deletes 'a' if writeA has enough access.
// #
// ### Changing a protected property key ###
// #
Object.defineProperty(x, writeA, { protected: false });
let newWriteA = Object.protectProperty(x,
Re: Protected properties using Name objects
Addition to previous post on aliasProperty: you can only create alias on configurable property, of course. Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
I addressed some of these as well but didn't put it up here yet. Semantics (this is all on the gist as well in more readable form) * Objects keep an internal map of protector *Name* objects to keys. * A protector can only protect one key per object. * Each key on an object can only have one protector (this isn't necessary but seems preferable). * The key a protector protects can vary between objects. * The protector for an object's key can be changed. * A non-writable property's value can always be changed via the protector (but not direct assignment). * Setting an object to non-configurable makes it non-protected (they are mutually exclusive and configurability trumps). * By extension, a non-configurable property cannot become protected. * For Accessors, the __public__ property of the protector is passed to the setter (matches how private Names work with Proxies). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Erik Arvidsson wrote: On Fri, Jun 15, 2012 at 6:28 AM, T.J. Crowdert...@crowdersoftware.com wrote: Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't _need_ it), Brendan's (too thin)[1], and Herby's (wouldn't hurt)[2]. Since you are asking for opinions. I don't want it. It doesn't carry its own weight. If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise. So the summary (sorry if it didn't do Herby's position justice; I'm using it as a whipping boy here) of wouldn't hurt is simply not an argument for new operators to shorten hard cases. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
Note: Given the above constraints on configurability, no norms are violated in this. A non-writable property is writable currently using Object.defineProperty. It's just not writable directly, which is upheld here. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
Le 15/06/2012 21:27, Brandon Benvie a écrit :
Currently there's no way to have a data property that is writable by
some but not all.
My heartbeat reaction to this first sentence is: is it a use case anyway?
This can't even really be achieved with accessors or proxies directly.
Rather, the underlying data is mutated through some other avenue, and
the value returned on access comes from this secondary source. Neither
method of course is remotely as efficient as a real data property as
either.
I disagree with that statement (but until direct proxies are efficiently
implemented, it's hard to tell who is right :-) ).
var o = {a:1, b:2};
var o2 = makeProxyWithSomeReadOnlyProperties(o, ['a']);
The makeProxyWithSomeReadOnlyProperties creates a proxy with o as
target. Only property-mutation-operation traps need to be implemented
(read traps are the forward-to-target default ones). In this
configuration, at least the reads on o2 can be made as efficient as the
read in o (since the engine knows the target and knows that read traps
are the default ones, so it can delegate the operation to the target
with no overhead)
There is certainly an overhead for write operations (since you need to
check whether the property is readOnly or not). It is unclear whether
it's so much more than it wouldbe natively to justify a direct native
implementation in my opinion.
The reason why it's unclear is also that a new property descriptor
attirbute like the one your propose may deteriorate the performance of
all write operations on all objects (since a new check may be necessary).
It seems to me that your proposal could be implemented in pure ES.next
(not on existing objects, though). I'd be interested in seeing it
implemented and used in real world examples. Only then will we be able
to tell whether there are use cases and whether, on these use cases, the
performance is bad enough and not improvable to justify native
implementations.
A nit on your API:
Object.protectProperty(object : Object, currentProtector : Name) - true
unprotects the key on object which currentProtector protects
= I don't think Object.protectProperty should ever unprotect something.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
Actually I'm working on implementing it now. I previously partially
implemented Names which is half the equation (though only in V8) and this
is just an extension to that.
There shouldn't need to be any additional checks using what I've proposed.
A non-writable property is no more writable than it currently is, and in no
different a way. Right now you can write to a non-writable property by
doing Object.defineProperty(o, k, { value: v }). This proposal uses Name
objects to make that look cleaner. It also actually adds increased
protection that doesn't exist, since it closes the defineProperty route of
modifying a read-only property entirely unless you have the key.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 15, 2012, at 12:33 PM, David Herman wrote: So I favor ?? as well as both ||= and ??=. Adding ||= and ??= without = will cause my symmetry-reflex to twitch, despite not seeing a purpose for it I may find it hard to resist supporting that too. ;-) G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
satyr wrote: On Sat, Jun 16, 2012 at 4:33 AM, David Herman dher...@mozilla.com mailto:dher...@mozilla.com wrote: As for null, I can see how there's confusion about whether to use null vs undefined, and so I can see why CoffeeScript would just try to blur the distinction between them. Not just for blurring. Rejecting `null` is essential for CoffeeScript's existence due to `?.`, the soak/safe access operator. Can you give a real-world example where null rather than undefined is soaked up? I'm guessing DOM but guessing is bad (cf. Sherlock Holmes). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[strawman:data_parallelism]] |this| and fat arrows
On Fri, Jun 15, 2012 at 11:35 PM, Hudson, Rick rick.hud...@intel.com wrote: Hey Mark, ParallelArray and index are left out because of our desire to provide a few good methods that help/force programmers to think about parallel algorithms and not just speeding up sequential algorithms. Array map is really just syntactic sugar for for loops and invites thinking that depends on order. For ParallelArray map we felt that the value was the semantically important thing and the user should not be distracted by the index. Not having index available is one step towards thinking in more parallel ways. Hi Rick, the claim made in the paragraph above seems to be the core argument. I respect the kind of argument you're making -- programmer psychology is important, and it is our responsibility as language designers to take it into account, and to help steer programmers towards certain ways of thinking about the problem and away from others. Sometimes these psychological issues have no corresponding formal basis, but are still important nevertheless. Arguments by non-psychologists like us about psychology can often be fuzzy, but this does not relieve us of responsibility of taking these into account. However, I don't have any intuition that supports the specific claim. Let's take map specifically. How/why might including index and the array itself distract the programmer from parallel thinking? First, do we agree that there's no formal problem, and the issue is only psychology? If so, perhaps you could provide some examples that would help illustrate the psychological issue you have in mind? At this point, I just don't get it. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Fri, Jun 15, 2012 at 6:00 PM, Brendan Eich bren...@mozilla.com wrote: Can you give a real-world example where null rather than undefined is soaked up? I'm guessing DOM but guessing is bad (cf. Sherlock Holmes). Wouldn't any case where you return null to mean explicitly no object be such a case? Ie: var bar = lookupFoo(key)?.bar(); -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Maybe, probably, of course ;-). I'm still looking for real-world use-cases, code that actually exists (in CoffeeScript or JS) that needs to soak up null-or-undefined, not just undefined. /be John Tamplin wrote: On Fri, Jun 15, 2012 at 6:00 PM, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: Can you give a real-world example where null rather than undefined is soaked up? I'm guessing DOM but guessing is bad (cf. Sherlock Holmes). Wouldn't any case where you return null to mean explicitly no object be such a case? Ie: var bar = lookupFoo(key)?.bar(); -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On 15 June 2012 22:22, Brendan Eich bren...@mozilla.org wrote: If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. Who said it was? New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise. I'm sorry: botched?! What exactly is botched about this? In fact, I don't think I was pushing any particular syntax. I think I was clear about asking _whether_ people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question? -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
T.J. Crowder wrote: On 15 June 2012 22:22, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. Who said it was? You summarized Herby to that effect: Herby's (wouldn't hurt)[2]. ... [2] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023510.html New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise. I'm sorry: botched?! What exactly is botched about this? You are misreading my generic words. I'm not talking about a proposal of yours, or of mine. In fact, I don't think I was pushing any particular syntax. I think I was clear about asking _whether_ people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question? I was describing the hazards of adding syntax that wouldn't hurt. Syntax should be added only when it clearly helps: * It brings new semantics not expressible in the language (let, const, modules, generators). * It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Brendan Eich wrote: * It brings new semantics not expressible in the language (let, const, modules, generators). * It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded. Classes (maximally minimal, mainly for extends and super) is a prime example of the second bullet, IMHO. Apologies if my reply seemed targeted at you, or Herby for that matter. I was soap-boxing against the wouldn't hurt summary-argument. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
The gist now includes a rough implementation of this ( https://gist.github.com/2938186 ). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Announcing, June 15, 2012 ES6 Draft
Download it from: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes from May TC39 Review Tentative addition of Class Definitions Syntax and Semantics in 13.5 based upon Maximally Minimal Strawman. NOTE-Classes do not yet have full consensus within TC39 and may not survive. 11.1.5 make super references illegal in method definitions within object literals removed | and TriangleLiterals reverted methods to only have bracketed function bodies rather than concise bodies Removed Object.isObject Removed String.prototype.toArray Eliminated requirement for buggy daylight savings time adjustment Other changes 5.1.1 , 5.2 Defined “chain production” and implicit algorithm pass through for chain productions. Eliminated unnecessary pass through algorithms Eliminate final remnants of ES1 line number references within algorithm conventions Moved Literal from lexical to syntactic grammar Updated keywords list 10.1.2 /10.4 introduce concept of non-ECMAScript functions and execution contexts for them 11.1.4.2 tweaks to Array Comprehension syntax made it an early error to use a reserved word as a single identifier property definition shorthand added default value initializers to internal elements and properties of destructuring assignment patterns corrected major case statement semantic bug from ES5.1 made YieldExpressions illegal in parameter default value initializers made home object binding of methods contingent upon them actually referencing super added [[ThisMode]] internal property to functions via FunctionCreate to deal with lexical this binding in arrow functions made super references and yield expressions early errors in ProgramBody In Math.sign clarified handling of -0 Added String.prototype HTML wrapping functions to Annex B Merged ES5.2 Annex F into Annex DE Made Annex F an Informative Summary of Static Semantic algorithms Fixed bugs 340,351-354,356,358-361,364-367,369-376,378-380,382,384-38 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
