Re: Is ES5 Strict a fully statically scoped language?
On Oct 3, 2012, at 10:05 AM, François REMY wrote: In non-strict ES, the “t” function may be eval, and eval could add a “oops” variable in the parent function getOoops. I don't believe this is true. This does not constitute a direct call to eval (15.1.2.1.1), and as such the eval will take place in a fresh execution context, rather than the calling function's context. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Is ES5 Strict a fully statically scoped language?
On Oct 3, 2012, at 12:40 PM, François REMY wrote:
Indirect eval is something introduced for ES5 Strict only, I believe.
Nope. See 15.1.2.1.1, no reference to strict.
Here's a better example:
(function(t){ var x = 'foo'; t(x = 'bar'); alert(x); })(eval)
The indirect eval does not modify the function's local variable.
cheers,
G.
___
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: New Object Extension Literal Strawman
On May 29, 2012, at 11:19 PM, Brendan Eich wrote:
o.( a = alpha, b = beta )
v.
o.( a = alpha; b = beta )
The similarity between .{ foo: bar } .{ foo= bar } concerns me, it's too
footgunish. This I like.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode based on UTF-16 proposal
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 explicitly opt-out of correct unicode support (since little consideration usually seems to be given to this topic), and as discussed previously, a mechanism to do so already exists if they need it (RegExp(foo) will behave the same as the proposed /foo/U). If we do add a 'U' flag, I'd worry that it may end up more commonly being used in error when people intended to append a 'u'! cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Finding a safety syntax for classes
On Mar 23, 2012, at 12:42 AM, Claus Reinke wrote: - would it make sense to name the constructor after the class (avoiding 'constructor' and 'new')? I was about to suggest exactly the same thing. If I see a line of code saying let x = new FooBar(); and want to understand what it does, I'm instinctively looking for a function named FooBar, not one named either 'new' or 'constructor'. Between 'new' and 'constructor', new seems like the better choice to me. Whilst it is true that prototypes currently contain a constructor property, I don't see a lot of code that explicitly accesses this. In terms of the language actually actively in use in scripts by ES programmers, 'new' is currently in the common lexicon, and 'constructor' doesn't seem to be. [ I make this statement on casual observation rather than any empirical evidence. :-) ] cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Finding a safety syntax for classes
Yeah, I forgot about anonymous classes again. :-)
Sadly (as a fan of using the classname) I so think that's a good argument.
G.
On Mar 23, 2012, at 10:27 AM, Brendan Eich wrote:
Yet didn't we go over this previously?
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015014.html (from you
;-)
in reply to
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015012.html (from Bob
Nystrom)
It's also a bit novel to preempt the class name in its own prototype, but
usually ok. Any of {constructor, new, classname} is a special form as
noted. It's true that 'constructor' avoids collision but OTOH, it's overlong.
None of these names avoids magic wiring behind the scene.
Someone on twitter pointed out that class name minifies well, but so does
constructor, and anyway transport-encoding compression makes this moot.
Anonymous classes are an important use case IMHO, to match anonymous
functions and the prototypal pattern.
/be
Gavin Barraclough wrote:
On Mar 23, 2012, at 12:42 AM, Claus Reinke wrote:
- would it make sense to name the constructor after the class
(avoiding 'constructor' and 'new')?
I was about to suggest exactly the same thing.
If I see a line of code saying
let x = new FooBar();
and want to understand what it does, I'm instinctively looking for a
function named FooBar, not one named either 'new' or 'constructor'.
Between 'new' and 'constructor', new seems like the better choice to me.
Whilst it is true that prototypes currently contain a constructor property,
I don't see a lot of code that explicitly accesses this. In terms of the
language actually actively in use in scripts by ES programmers, 'new' is
currently in the common lexicon, and 'constructor' doesn't seem to be. [ I
make this statement on casual observation rather than any empirical
evidence. :-) ]
cheers,
G.
___
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: simpler, sweeter syntax for modules
On Mar 21, 2012, at 3:28 PM, David Herman wrote:
* importing with renaming:
import { draw: drawGun }from cowboy.js,
{ draw: drawWidget } from widgets.js;
Hey Dave,
This all looks really nice! - the only thing that threw me was the export
rename – I intuitively expect the think on the left of the colon to be the new
name, not the old one. I guess my expectation comes from existing JS: :-)
var oldName = 42;
var o = { newName: oldName };
The contextual 'as' looks nice to me for module renames, and would make the
direction of the renaming clear - was this been considered for the exports too?
import { draw as drawGun } from cowboy.js,
{ draw as drawWidget } from widgets.js;
Also, are the braces necessary to parse this? Perhaps they could be omitted?
import draw as drawGun from cowboy.js;
cheers,
G.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Testcase 15.2.3.6-4-123
Hi Bernd,
You're assuming that the descriptor is a generic descriptor - that isn't the
case (accessor descriptors don't have a writable property), see 8.10.2,
IsDataDescriptor.
As such, we don't return from step 8 of 8.12.9, and instead reach step 10.a.i.
cheers,
G.
On Mar 19, 2012, at 11:53 AM, Bernd Buschinski wrote:
Hello,
I am having trouble understanding where testcase 15.2.3.6-4-123 should fail
according to the ecma262 5.1 Document.
I get why it should fails, but not in which step exactly.
I really think I am just getting something wrong so I will write down
everything what I think happens.
If you spot the error please correct me :)
++The Testcase:
/// Copyright (c) 2012 Ecma International. All rights reserved.
/**
* @path ch15/15.2/15.2.3/15.2.3.6/15.2.3.6-4-123.js
* @description Object.defineProperty - 'O' is an Array, 'name' is the length
property of 'O', the [[Value]] field of 'desc' is absent, test TypeError is
thrown when updating the [[Writable]] attribute of the length property from
false to true (15.4.5.1 step 3.a.i)
*/
var arrObj = [];
try {
//1. call
Object.defineProperty(arrObj, length, {
writable: false
});
//2. call
Object.defineProperty(arrObj, length, {
writable: true
});
return false;
} catch (e) {
return e instanceof TypeError;
}
++The Calls:
//1. Call
Array.[[DefineOwnProperty]](length, desc{writable: false}, true)
1.
oldLenDesc = [[GetOwnProperty]](length)
// oldLenDesc = { value: 0, writable: true, enumerable: false, configurable:
false }
2.
oldLen = oldLenDesc.[[value]]
// oldLen = 0
3. if P == length // true
3.a. if value of desc is absend
//true
3.a.i return default [[DefineOwnProperty]](length, desc{writable: false},
true)
// - call 8.12.9
//8.12.9 [[DefineOwnProperty]] (length, desc{writable: false}, true)
1. current = [[GetOwnProperty]](length)
// current = { value: 0, writable: true, enumerable: false, configurable:
false }
2. extensible = [[Extensible]]
//extensible = true;
3. + 4. if current is undefined and ... (does not apply)
//false
5. if desc is empty
//false
6. if desc is current
//false, different in writable
7. if current.[[configurable]] is false
//true
7.a. if desc.[[configurable]] is true ...
//false, because not set, defaults to not configurable
7.b. if desc.[[Enumerable]] is true AND desc.[[Enumerable]] != current.
[[Enumerable]]
//false
8. If IsGenericDescriptor(Desc) is true, then no further validation is
required.
//true, jump to step 12+13
Final: put length, { value: 0, writable: false, enumerable: false,
configurable: false }
1. Call Done.
length == { value: 0, writable: false, enumerable: false, configurable: false
}
===
//2. Call
Array.[[DefineOwnProperty]](length, desc{writable: true}, true)
1.
oldLenDesc = [[GetOwnProperty]](length)
// oldLenDesc = { value: 0, writable: false, enumerable: false, configurable:
false }
2.
oldLen = oldLenDesc.[[value]]
// oldLen = 0
3. if P == length // true
3.a. if value of desc is absend
//true
3.a.i return default [[DefineOwnProperty]](length, desc{writable: true},
true)
// - call 8.12.9
//8.12.9 [[DefineOwnProperty]] (length, desc{writable: true}, true)
1. current = [[GetOwnProperty]](length)
// current = { value: 0, writable: false, enumerable: false, configurable:
false }
2. extensible = [[Extensible]]
//extensible = true;
3. + 4. if current is undefined and ... (does not apply)
//false
5. if desc is empty
//false
6. if desc is current
//false, different in writable
7. if current.[[configurable]] is false
//true
7.a. if desc.[[configurable]] is true ...
//false, because not set, defaults to not configurable
7.b. if desc.[[Enumerable]] is true AND desc.[[Enumerable]] != current.
[[Enumerable]]
//false
8. If IsGenericDescriptor(Desc) is true, then no further validation is
required.
//true, jump to step 12+13
Final: put length, { value: 0, writable: true, enumerable: false,
configurable: false }
2. Call Done.
length == { value: 0, writable: true, enumerable: false, configurable: false }
So thats how I see what happens and I can not see where it fails. Please
enlighten me :)
___
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: Question about Array.prototype.slice
I believe behaviour is defined by the fourth paragraph of chapter 15: Unless otherwise specified in the description of a particular function, if a function or constructor described in this clause is given fewer arguments than the function is specified to require, the function or constructor shall behave exactly as if it had been given sufficient additional arguments, each such argument being the undefined value. The missing arguments are treated as undefined, and ToUint32/ToInteger both convert undefined to 0. cheers, G. On Mar 13, 2012, at 1:36 PM, Rick Waldron wrote: Sorry, I meant 15.4.4.10 On Tue, Mar 13, 2012 at 4:28 PM, Rick Waldron waldron.r...@gmail.com wrote: A little different then the usual fare... When interpreting (for the sake of implementation) how the arguments of Array.prototype.slice should be handled: is it safe to assume that arguments may not be defined and that all implementations are expected to handle this the same way, as specified by 15.4.4.9? Put another way - no part of Array.prototype.slice's argument handling could be mis-interpreted by an implementor, without being considered a bug, correct? I apologize if this has an obvious answer and I believe it does, I'm just hoping to get confirmation. Thanks in advance. ___ 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: How about replacing | with -
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a clear
directionality in the operation (e.g. chasing a chain of pointers in C), but
the lack of consensus as to which direction the arrow should point in seems
likely to be indicative of a larger problem - that either choice is going to be
backwards, unintuitive, and confusing for a significant proportion the users.
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.S.: Maybe even
let sub = sup offspring {p:1, q:2, r:3};
P.P.S.: I don't know what 'beget' means (I know I can find it, just to
illustrate it's not a commonly known word).
Apologies in advance for using a four letter word, but the following is simple,
a common word, is becoming available, and reads well to me:
let sub = sup with {p:1, q:2, r:3};
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On Feb 20, 2012, at 8:37 AM, Brendan Eich wrote: BRS makes 21-bit chars, so just as String.prototype.charCodeAt returns a code point, String.fromCharCode takes actual code point arguments. Again I'd reject (dynamically in the case of String.fromCharCode) any in [0xd800, 0xdfff]. Other code points that are not characters I'd let through to future-proof, but not these reserved ones. Also any 0x10. Okay, gotcha – so to clarify, once the BRS is thrown, it should be impossible to create a string in which any individual element is an unassigned code point (e.g. an unpaired UTF-16 surrogate) – all strings elements should be valid unicode characters, right? (or maybe a slightly weaker form of this, all string elements must be code points in the ranges 0...0xD7FF or 0xE000...0x10?). Implementations that use uint16 vectors as the character data representation type for both UCS-2 and UTF-16 string variants would probably want another flag bit per string header indicating whether, for the UTF-16 case, the string indeed contained any non-BMP characters. If not, no proxy/copy needed. If I understand your original proposal, you propose that UCS-2 strings coming from other sources be proxied to be iterated by unicode characters (e.g. if the DOM returns a string containing the code units \uD800\uDC00 then JS code executing in a context with the BRS set will see this as having length 1, right?) If so, do you propose any special handling for access to unassigned unicode code points in UCS-2 strings returned from the DOM (or accessed from another global object, where the BRS is not set). e.g. var ucs2d800 = foo(); // get a string containing \uD800 from the DOM, or another global object in BRS=off mode; var ucs2dc00 = bar(); // get a string containing \uDC00 from the DOM, or another global object in BRS=off mode; var a = ucs2d800[0]; var b = ucs2d800.charCodeAt(0); var c = ucs2d800 + ucs2dc00; var c0 = c.charCodeAt(0); var c1 = c.charCodeAt(1); If the proxy is to behave as is the UCS-2 sting has been converted to a valid unicode string, then I'm guessing that conversion should have converted the unmatched surrogates in the UCS-2 into unicode replacement characters? – if so, the length of c in the above example would be 2, and the values c0 c1 would be 0xFFFD? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On Feb 19, 2012, at 3:13 PM, Allen Wirfs-Brock wrote: My implementor's bias is showing, because I expect many engines would use UTF-16 internally and have non-O(1) indexing for strings with the contains-non-BMP-and-BRS-set-to-full-Unicode flag bit. A fine implementation, but not observable. Another implementation approach that would preserve O(1) indexing would be to simply have two or three different internal string representations with 1, 2, or 4 byte internal characters. (You can automatically pick the needed character size when the string is created because string are immutable and created with their value). A not-quite O(1) approach would segment strings into substring spans using such an representation. Representation choice probably depends a lot on what you think are the most common use cases. If it is string processing in JS then a fast representations is probably what you want to choose. If it is just passing text that is already UTF-8 or UTF-16 encoded from inputs to output then a representation that minimizing transcoding would probably be a higher priority. One way in which the proposal under discussion seems to differ from the previous strawman is in the behavior arising from concatenation of strings ending/beginning with a surrogate hi and lo element. How do we want to handle how do we want to handle unpaired UTF-16 surrogates in a full-unicode string? I can see three options: 1) Prohibit values from strings that do not map to valid unicode characters (either throw an exception, or replace with the unicode replacement character). 2) Allow invalid unicode characters in strings, and preserve them over concatenation – (\uD800 + \uDC00).length == 2. 3) Allow invalid unicode characters in strings, but allow surrogate pairs to fuse over concatenation – (\uD800 + \uDC00).length == 1. It seems desirable for full-unicode strings to logically be a sequence of unicode characters, stored and processed in a encoding-agnostic manner. option 3 would seem to violate that, exposing the underlying UTF-16 implementation. It also loses a distributive property of .length over concatenation that I believe is true in ES5 for strings, in that currently for all strings s1 s2: s1.length + s2.length == (s1 + s2).length However if we allow concatenation to fuse surrogate pairs into a single character (e.g. s1 = \uD800, s2 = \uDC00) this will no longer be true. I guess I wonder if it's worth considering either options 1) or 2) – either prohibiting invalid unicode characters in strings, or consider something closer to the previous strawman, where string storage is defined to be 32-bit (with a BRS that instead of changing iteration would change string creation, introducing an implicit UTF16-UTF32 conversion). cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On Feb 19, 2012, at 10:05 PM, Allen Wirfs-Brock wrote:
Great post. I agree 3 is not good. I was thinking based on today's exchanges
that the BRS being set to full Unicode *could* mean that \u is
illegal and you *must* use \u{...} to write Unicode *code points* (not
code units).
Last year we dispensed with the binary data hacking in strings use-case. I
don't see the hardship. But rather than throw exceptions on concatenation I
would simply eliminate the ability to spell code units with \u
escapes. Who's with me?
I think we need to be careful not to equate the syntax of ES string literals
with the actual encoding space of string elements. Whether you say \ud800
or \u{00d800}, or call a function that does full-unicode to UTF-16
encoding, or simply create a string from file contents you may end up with
string elements containing upper or lower half surrogates.Eliminating the
\u syntax really doesn't change anything regarding actual string
processing.
What it might do, however, is eliminate the ambiguity about the intended
meaning of \uD800\uDc00 in legacy code. If full unicode string mode
only supported \u{} escapes then existing code that uses \u would have to
be updated before it could be used in that mode. That might be a good thing.
Ah, this is a good point. I was going to ask whether it would be inconsistent
to deprecate \u but not \xXX, since both could just be considered shorthand
for \u{...}, but this is a good practical reason why it matters more for \u
(and I can imagine there may be complaints if we take \xXX away!).
So, just to clarify,
var s1 = \u{0d800}\u{0dc00};
var s2 = String.fromCharCode(0xd800) + String.fromCharCode(0xdc00);
s1.length === 2; // true
s2.length === 2; // true
s1 === s2; // true
Does this sound like the expected behavior?
Also, what would happen to String.fromCharCode?
1) Leave this unchanged, it would continue to truncate the input with ToUint16?
2) Change its behavior to allow any code point (maybe switch to ToUint32, or
ToInteger, and throw a RangeError for input 0x10?).
3) Make it sensitive to the state of the corresponding global object's BRS.
If we were to leave it unchanged, using ToUInt16, then I guess we would need a
new String.fromCodePoint function, to be able to create strings for non-BMP
characters? Presumably we would then want a new String.codePointAt function,
for symmetry? This would also raise a question of what String.charCodeAt
should return for code points outside of the Uint16 range – should it return
the actual value, or ToUint16 of the code point to mirror the truncation
performed by fromCharCode?
I guess my preference here would be to go with option 3 – tie the potentially
breaking change to the BRS, but no need for new interface.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Perhaps I am overly fatalistic here, but if we don't specify an iteration order I think the web will just go and specify it for us, as it has for object property iteration order. We can bet against history repeating itself if we wish. On Feb 14, 2012, at 7:13 PM, Brendan Eich wrote: Mark Miller is holding up the argument for determinism really well. I'm not sure anyone disagrees with his points. We should look into deterministic data structures and measure the performance. Agreed. *nod. On Feb 13, 2012, at 6:03 PM, Mark S. Miller wrote: Before getting too deep into iteration protocol for Sets (and Maps) there is a more fundamental issues: Will Set define a standard, implementation independent ordering of elements? If so, what is the basis for the ordering? Yes. Insertion order. Mark, Do you think we want strict insertion order, including for numeric index properties? I guess I'm thinking the obvious here ( http://wiki.ecmascript.org/doku.php?id=strawman:enumeration ), but it would seem a simplest for users if there were a single story for iteration order. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 12, 2012, at 11:28 AM, Brendan Eich wrote: Heh, I knew that was coming. I'll amend to say of long standing after implementations :-P. :-D I still have a gut feeling that someone is going to take advantage of the setter for bad purposes that will be harder to block than would be the case if __proto__ reflected as a data property. But I can't prove this. Understood. We needed to change our implementation to fix ES5 compatibility issues with our prior mechanism. Implementing this internally as a accessor is much cleaner for us, and I think we'd want to keep it implemented this way even if we were to add the magic necessary to allow us to make it masquerade as a data descriptor (I still firmly side with Mark's strawman as to how this should be presented to users, but I didn't intend our current implementation to preclude alternatives). cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 13, 2012, at 9:55 AM, Allen Wirfs-Brock wrote: Finally, an alternative to extending [[Get]] and [[Put]] would be to extend the GetValue abstraction operation (8.7.1) and the Simple Assignment evaluation semantics (11.13.1). [[DefineOwnProperty]] and [[Delete]] still need to be extended but, independent of any of the above, these two can probably be made over-riding implementations on Object.prototype rather than extending the default implementations used by all objects. Hi Allen, I don't know if this is helpful, but Mark's strawman seemed to make this much simpler, perhaps it might make for a less intrusive specification to define that this should behave as if it is an accessor property following Mark's ProtoGetter/ProtoSetter descriptions, whilst leaving how the property is reflected ambiguous? I think this should amount to the same thing, just might be easier to encapsulate this way? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 10, 2012, at 11:55 AM, Brendan Eich wrote: over-specifying, right? I am in favor of specifying __proto__ minimally in Annex B. But, one thing I would like enshrined in the spec is that `__proto__ in Object.create(null) === false`. For sure! The idea of a minimal specification sounds really encouraging. It seems there are a few really key points that everyone appears to be in complete agreement on – that the __proto__ property should be a member of the Object Prototype, that this should be the only mechanism available to change an object's prototype, and that it should be configurable. On Feb 10, 2012, at 3:16 PM, Brendan Eich wrote: I know of no implementations that reflect __proto__ as an accessor, WebKit is using an accessor in nightly builds. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote: I would expect Gavin's approach to ultimately be even worse than mine from a semantic analysis perspective. It expose (via Object.getOwnPropertyDescriptor) functions that have the ability to mutate any object's [[Prototype]] property and one those functions are exposed they can be installed as methods or explicitly called at any time. I think that tame them is likely to have even greater impact than what I have done. Certainly, for the ES5 language level (which is what my current spec. addresses) there is no way to talk about frames or the association of one of these functions or any other object with a frame. With my approach there is no need to match the proto mutator function's frame with the target object's frame, because there is no mutator function. Hi Allen, I completely agree with you that frame-based checks should not be a part of the solution, however they are no more necessary if __proto__ is an accessor property then if it is a data descriptor. The solution I proposed was that the [[ProtoSetter]] should hold a private reference to the Object Prototype upon which it is initially assigned, and that upon being invoked it should walk the this object's prototype chain to see if it any entry matches the stored value. With a check such as this in place (I expect there are other ways we could achieve this), it would not be possible to apply a given [[ProtoSetter]] to any object other than those upon which it would initially have been available to operate via the Object Prototype. Finally there is the object literal issue which was not address by the original wiki proposal. You're right, we do need to expand the proposal to cover this. This doesn't seem too difficult. If the identifier being assigned to in an object literal initialization is __proto__, then check whether the Object Prototype contains a property named __proto__ whose descriptor has a set value equal to that Object Prototype's original [[ProtoSetter]] function, if so then the assignment sets the newly constructed object's prototype, otherwise it defines a own property as usual. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 10, 2012, at 12:43 AM, David Bruant wrote: Maybe I'm missing something, but what you're proposing is *exactly* a frame-based check. Hi David, No, the proposed check does not correlate exactly to a frame-based check. For example, an object created using Object.create(null) may be associated with the same frame as a [[ProtoSetter]] function, but the restriction I propose would inhibit the object's prototype from being modified, where a same-frame check would. The check I am proposing is more restrictive. Also, and importantly (as Allen identifies), the proposed check does not require the spec to talk about frames or their association to objects. On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote: Certainly, for the ES5 language level (which is what my current spec. addresses) there is no way to talk about frames or the association of one of these functions or any other object with a frame. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Jan 28, 2012, at 3:58 PM, Allen Wirfs-Brock wrote: Since most implementations already seem to have special mechanism for giving magic behavior to certain properties I would expect them to use some of those mechanisms here. No - in JSC I'm pretty sure it's going to be faster and cleaner to implement this as a regular accessor property. Now, it would certainly be possible to add a mechanism to allow this accessor to masquerade itself as a data property, but it just seems too magical and unnecessarily weird to do so. It behaves like an accessor, so it should look like one. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
Hi Allen,
On Jan 29, 2012, at 4:25 PM, Allen Wirfs-Brock wrote:
There are no rules that constrain [[Put]] in this manner you are suggesting.
Sorry, perhaps my comments were unclear. The observation I was intending to
highlight was only that the current behaviour of [[Put]] will be to call
[[DefineOwnProperty]] on a base object that is not the object that logically
contains the 'magic' property, if the __proto__ is specified as a data
descriptor.
E.g.
Object.prototype.__p__ = 1;
var a = {};
a.__p__ = 2;
The [[Put]] of '2' will call the [[DefineOwnProperty]] trap of 'a', not the
object that currently contains a data descriptor for __p__.
Hence (as I think you recognize in your comments), it would not simply be
sufficient to provide an overridden implementation for [[DefineOwnProperty]]
for the object prototype. This does mean that the 'magic' behaviour cannot be
as easily and cleanly encapsulated as it can for Array, where the 'magic'
properties are directly on the base object passed to [[DefineOwnProperty]].
This seems like a perfectly reasonable way to specify this. As __proto__
does indeed affect the property access semantics for every object. Of
course, I'm only talking specification. How you accomplish it in your
implementation is up to you.
There are other, alternatives.
I'm not questioning for a minute that this is possible – it certainly is – I'm
just stating that it seems to be completely unnecessary, confusing, and not a
good idea to do so. :-) Seriously, why are we doing this? – __proto__ is an
accessor, it's much simpler to just spec it as such, why are we trying to set
up hoops for ourselves to jump through to avoid doing so?
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Jan 20, 2012, at 4:07 PM, David Bruant wrote: * What are all the cases in nowadays browsers where a new Object.prototype.__proto__ can be dynamically created? (The only one I can think of is same-domain iframe, but I think there exists some weird rules for one frame to access another by changing its own domain to a subdomain, or something like this) * For each case, who has access to the other first? The creater or the creature? * One difference that is made in the accessor case is that if one party runs before the other, then this first one can keep a reference to the setter. Does this increase the already existing attack surface? Hi David, It seems that the best way to neutralize the thread from new __proto__ instances, would be to simply prohibit __proto__ taken from one iframe to be applied to objects created in another. I think this should be achievable with the following tweaks to the strawman: * The [[ProtoSetter]] method holds a private reference [[OwnerObjectPrototype]] to the ObjectPrototype upon which . * Add a step 2b to the definition of [[ProtoSetter]](Parent), specifying: Walk the prototype chain of O, comparing each successive prototype to the stored [[OwnerObjectPrototype]]. If the prototype chain does not contain [[OwnerObjectPrototype]], throw a TypeError. What do you think? – are there holes this leaves open? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
Le 28/01/2012 18:16, Brendan Eich a écrit : I don't think we should change __proto__ unnecessarily from current implementations, including making it an accessor. Neither JSC nor SpiderMonkey does that. If the spec includes an optional normative definition of __proto__ that requires it to be a configurable property of Object.prototype then a significant rewrite of JSC's __proto__ implementation will be necessary. That's okay – it seems worthwhile doing so to make it possible to delete the __proto__ property. The logical way to implement this in JSC is likely as an accessor property. So the question for us is not whether changing our implementation is necessary (it is), but rather whether having cleaned this up, we will then need to add back in new magic to make __proto__ masquerade as a data descriptor to match SpiderMonkey. The less magical __proto__ is the better, so this seems undesirable. Since the implementation in JSC will need to change anyway, we're motivated to aim for the least magical behaviour, but for SpiderMonkey, which already has a better implementation for __proto__, I can see why requiring a change would be undesirable. On Jan 28, 2012, at 10:20 AM, David Bruant wrote: Regarding the specification (as optional normative) of __proto__ as an data descriptor, either the spec can invoke some magic (which is what implementations already do from an ES5 point of view) or redefine Object.prototype as a proxy. The target of this proxy would be the standard Object.prototype and the handler would just define some trap behavior that deal with __proto__. Given this is __proto__ we're talking about, maybe it just isn't worth being overly specific here? How about we just specify that: * The only permissible way to modify an object's [[Prototype]] is through __proto__. * __proto__ must be a property of Object.prototype. * __proto__ must be configurable. This would mean that any conforming implementation would have a easy, spec-defined way to remove __proto__, without burdening browsers who implement this as a data descriptor to change their implementations to make it an accessor descriptor, or burdening browsers who implement this as an accessor descriptor to change their implementations to make it a data descriptor. Are there a significant practical benefit of a more restrictive specification that this fails to cover? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: shortcuts for defining block-local private names, plays nicely with @foo syntax
On Jan 22, 2012, at 10:29 PM, Brendan Eich wrote:
1) should .@ member access and @ object literal property definitions permit
he property key to be any toString-able value and not just private name
values? The current plan of record does not require a private name value in
the analogous contexts.
I'm slightly inclined towards requiring private name values, but would be
happy either way.
As noted above, I'm inclined toward requiring private name objects on the
right of @.
It seems like an unfortunate inconvenience to require any code refactoring and
lose the shorthand @ this-access if you just want to make a private property on
an object be public. Instead of just restricting the token to the right of a @
or .@ construct be a private name, perhaps it would be useful to also permit an
explicitly declared public name?
private x,y;
function point(x,y) {
@x = x;
@y = y;
}
can easily be transformed into:
public x,y;
function point(x,y) {
@x = x;
@y = y;
}
This would still provide a guard against typos, whilst giving convenient access
to public properties on the this object.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: shortcuts for defining block-local private names, plays nicely with @foo syntax
On Jan 23, 2012, at 12:27 PM, Brendan Eich wrote:
No, the private binding form that is desugared from
private foo;
to
const foo = Name.create(foo);
or better (with hygiene to use the right Name, etc.) is lexical in its
binding structure.
Is the intention here that the private name object would be in scope, and
accessible to the user? – if so, this does seem useful, but using the plain
name of the property seems potentially prone to typos, e.g.
let o = {};
{
private x:
o.setX = function(x) {
@x = x;
}
o.getX = function() {
return x; // should be 'return @x;'
}
}
I seems that this would be an easy mistake to make, and doesn't appear to be a
syntax error is x is in scope. Wanting to pass around the private name seems
like a less common use case, so perhaps it might be worth making it slightly
harder to get to the private name?, e.g.
const @@foo = Name.create(foo);
const @{foo} = Name.create(foo);
const @foo = Name.create(foo);
function getPrivateName() { return @@foo; }
function getPrivateName() { return @{foo}; }
function getPrivateName() { return @foo; }
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: shortcuts for defining block-local private names, plays nicely with @foo syntax
On Jan 23, 2012, at 1:11 PM, Brendan Eich wrote: Then I think we considered a proposal where private x; bound in a separate lexical chain but that chain was searched *only* on right of @. That proposal seemed not to have the readability drawback. It also solves the problem you show above? Ah, that's the detail that I'd missed! - if private names will be ignored if they are not to the right of @, then presumably my example *would* result in at least a reference error, since 'x' would not in scope in 'getX' (unless of course x resolves to the global object...). I was wrong in thinking that getX would return the private name? – if so, this sounds good to me! Do we want there to be a way to be able to get to a private name object declared by 'private foo;' syntax, or if developers want to get their hands on a private name objects that they can pass around should they just be calling Name.create directly? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
As well as pragmas, macro-expansion would be a possibility!define fn functionundef fnG.On Jan 20, 2012, at 6:40 PM, Brendan Eich wrote: Allen Wirfs-Brock January 20, 2012 5:41 PM At the TC39 meeting we were trying to think of pragma candidates.It wouldn't surprise me if JS programmer would happily trade one:use fn;per file in exchange for being able to use "fn" as a synonym for "function". In terms of character counts, you come out ahead starting with the second function definition.Allen I have considered this in the past. It always seemed too little, due to return. If it enabled another production: AssignmentExpression : fn Identifieropt ( FormalParameterListopt ) AssignmentExpression (or we just added this unconditionally, without the pragma -- but the pragma is good too) then I'd be happy, finally. /be ___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object as the global scope instance object
On Jan 20, 2012, at 4:23 PM, Allen Wirfs-Brock wrote:
I'm not yet convinced that you need to publicly expose such global object
properties accessor properties. I think it is possible to hide the
mechanisms.
I'm strongly inclined to agree with this sentiment – engine implementors might
choose internally to utilize accessors in their implementations, but from a
user perspective it seems to make much more sense that these remain as regular
data properties. It is worth bearing in mind that 'const' is already available
outside of strict mode and we need to be considerate of any breaking changes we
make to existing semantics. (We could define incompatible semantics for
strict-mode only, but this would likely lead to a confusing divergence in
semantics for users – it could be horribly confusing if const variables in
non-strict code were to be implemented as data properties whilst those in
strict code were defined as accessor properties).
alert('value' in Object.getOwnPropertyDescriptor(this, 'x'));
alert(Object.getOwnPropertyDescriptor(this, 'x').writable === true);
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
x = 1;
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
const x = 2;
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
x = 3;
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
This script tests the presence and writability of a property on the global
object, and the effect of attempting to assign to it in non-strict code. It
demonstrates a non-const var behaving as a regular non-writable property in
non-strict code.
On FireFox the above script outputs true, false, undefined, undefined, 2, 2,
which to my mind makes a lot of sense. It perfectly matches, as far as one can
test, any other regular non writable property that you could create on an
object (of course there it not normally the opportunity to split creation and
initialization of a non-writable property).
This behaviour is also sensibly consistent with that for let and var. Running
the above script, changing 'const' to 'var' outputs true, true, undefined, 1,
2, 3 (indicating the property is writable, and all assignments succeed), and
for 'let' currently also outputs true, true, undefined, 1, 2, 3 on FireFox.
To my mind this behaviour should probably change slightly. With a temporal
dead zone implemented I would expect an attempt to [[DefineOwnProperty]] to an
uninitialized value to be rejected (though I would not expect an exception to
be thrown from non-strict code) so I would expect the output for 'let' to be
true, true, undefined, undefined, 2, 3 (the assignment of 'a' silently fails
leaving the value unchanged).
I would suggest that specifying this as a piece of additional hidden internal
state on a data descriptor (rejecting attempts to define or access the value
prior to initialization, throwing in strict-mode silently ignoring in
non-strict) makes most sense on a number of grounds:
– compatibility with existing non-strict const implementations.
– consistency with appearance of var properties on the global object.
– consistency with appearance of regular non-writable properties on other
objects.
– consistency with behaviour of access to regular non-writable properties on
other objects.
– data properties typically have higher performance in implementations,
specifying all global let const properties to be accessors may introduce
unnecessary overhead.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Just a thought, has a prefix ^ been considered?A lambda that takes no arguments could be: ^{ /*...*/ }And a lambda with some arguments: ^(x,y){ /*...*/ }I just find this really readable, the syntax for lambdas that take no arguments is delightfully minimal (just one extra character!), my brain is well trained to expect argument lists to be delimitedby parentheses so I find this much easier to understand, and I find the ^ character pleasingly evocative ofλ. :-)cheers,G.On Jan 13, 2012, at 3:03 PM, Brendan Eich wrote:
The { and } around the ||
make it pretty clear the || is not a boolean. Also you can put a space
in {| |}. But mainly, as with any alternative bracketing system that
uses an infix operator, we are relying on the leading { to make it clear
that the immediately following delimiter, | in the proposal, cannot
represent its usual infix role (| or ||).
/be
john saylor
January 13, 2012
1:11 PM
yes, i had the same impression [thx to those who supplied code
examples].
one problem i came across in this domain is that a block lambda with
no
arguments is visually identical to a boolean or ['||']. context, i
believe, will clarify this; but from a purely visual perspective, two
adjacent pipe characters are almost archetypal for the boolean or
operator [if i can speak about archetypes in computer programming].
Rick Waldron
January 13, 2012
12:36 PM
FWIW, After working through the
example gists that I created last night, my opinion changed about the
look of Block Lambda's with pipes. As others on the list have said
previously and is now very clear to me, pipes provide a very distinct
visual cue "this is a block lambda, expect X to happen here" where the
{(args) expr } gets lost; these visual cues are important when you're
reading and writing "real world" programs in _javascript_.
Rick
___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock
January 13, 2012
10:51 AM
I've updated a
version of my ES.next Smalltalk collections implementation experiment to
use block lambdas.This version ishttps://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.jsThe
one that you should compare it to ishttps://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.jsAs
you might expect, this new version is even closer in form to the
original Smalltalk code.In particularly, I was able to
eliminate all the artifacts that needed to be introduced because of
function expressions don't have Tennent's Correspondence.In
the source, I've tagged the lines where TCP is using /*TCP*/Allen___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
john saylor
January 13, 2012
6:09 AM
hello world!
i think this would be very helpful too [although, sadly, since i am
overcommitted as it is, it will not be me].
David Herman
January 12, 2012
6:09 PM
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be used as a statement by itself. If it's the case, it should defined as an _expression_ only, where there's no anonymous block to conflict the syntax. That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for uses of a feature "in the wild." Does some enterprising es-discusser wanna take a big JS program with a bunch of little anonymous functions, swap them out with block lambdas, and make two gists with the two different syntaxes? That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous block in some future revision of ES, that very small edge case could vanish at the same time.
I don't understand what you're referring to here -- what do you mean by "unprefixed anonymous block?"
Does it seems possible/acceptable?
Lovely.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
x = y
^{z: w}
On Jan 18, 2012, at 9:05 AM, Oliver Hunt wrote:
Alas ^ is syntactically ambiguous in the non-argument case:
foo
^{...}
The ambiguity here doesn't seem particularly troubling. Under ASI this parses
in a sensible fashion.
This seems unlikely to cause any confusion in real usage, since it only effects
an object literal as an operand to a bitwise operator.
On the other hand, reuse of | seems somewhat more awkward. Based on the block
lambda revival proposal, I believe:
{|x = (ab)| x}
{|x = (ab)| x}
{|x = ab| x}
Are all valid block lambdas, but:
{|x = ab| x}
Isn't.
Allowing an arbitrary subset of infix operators in initializer expressions
seems an unfortunate wart, and potentially confusing to users of the language.
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
2. The TCP conformance makes anything like function (params) {body} an
anti-pattern. Changing function to ^ does not avoid this problem. We want
block-lambdas to look different from functions.
(2) is an overriding objection in my view.
That's a fair point.
For my tastes reusing | as delimiters to the parameter lists is a step too far
away from function-like syntax, particularly if it restricts an arbitrary
subset of infix operators from initializers.
I'd suggest changing the terminator for the parameter list to something other
than | ...
{|: foo() }
{|x,y: foo(x,y) }
But I'd hate myself if I did. ;-)
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote: I think the state machine is over-complicating things. What it boils down to is that we are defining a new language, ES6-proper (or informally ES6 for short). It overlaps with ES5 but does not include it (e.g. throws out `with'). Then your state machine simply says, declaratively: - If a program is ES5 but not ES6, treat as ES5. - If a program is ES6 but not ES5, treat as ES6. - If a program is both ES5 and ES6, with identical semantics, treat as ES6 (although it doesn't matter). - If a program is both ES5 and ES6, with different semantics, treat as ES5 (for compatibility). - If a program is neither ES5 nor ES6, it's an error (obviously). If the a program is both ES5 and ES6 with identical semantics, then presumably we could equally treat it as ES5 with no behavior change? If so, couldn't this be stated in a much simpler fashion: - If a program is ES5, treat as ES5. - If a program is not ES5 but is ES6, treat as ES6. - If a program is neither ES5 nor ES6, it's an error (obviously). cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 2:22 PM, Claus Reinke wrote: Could you please clarify for me: if I get a single-file codebase, say jquery's 6k or so lines, will I have to scan the whole file for ES6-only features before I can even tell whether to apply ES6 or ES5 semantics? And will this problem increase by one level with every future version of ES? Btw, I'm really uncomfortable with implicit feature tracking - it works ok for people who follow all the relevant mailinglist discussions and spec versions, but it leaves in the dark all those who just code in JS and enter a situation where their code base might have to be interpreted according to any of a number of specs (most JS coders do not even read one version of the spec, but rely on blogs and books, which will equally show no explicit in-source sign of what spec version their examples refer to and whether they are out of date). I share these concerns. Would the implicit opt-in proposal not mean that any programmer wanting to pick up JavaScript would need to learn the history of when different syntactic constructs came into the language specification in order to understand the semantics that a given script would be evaluated with? G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: Remember, we are not proposing breaking semantic shifts of meaning for existing syntax. So the realistic worry is that you have code with arguments[i] aliasing a formal, and this is required for correct operation, and you then start using ES6 features (which imply ES5-strict), which breaks arguments aliasing. Hmmm, I was thinking this proposal implied much more of a breaking change (e.g. removing the global object from scope), but if the change in semantics largely comes down to enabling ES5-strict then maybe this isn't so bad. If we are talking about implicitly enabling ES5-strict for the whole program, I would think there may be a quite a few more hazards to consider? (code that implicitly introduces variables onto the global object, assumes this conversion to global object value in function calls, uses callee/caller/arguments, etc). Still, I'm warming up to the idea considerably if the implicit opt-in is triggering no major breaking changes. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 2, 2012, at 11:45 PM, Axel Rauschmayer wrote: Prefix might work, too. ¿x? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 12:18 PM, Brendan Eich wrote: Maybe. We tried in 2006-2007 and ran into at least this: https://bugzilla.mozilla.org/show_bug.cgi?id=351515 where 'yield' was used as a parameter name. I dimly recall 'let' in the wild but may be misremembering. Perhaps out of paranoia we made both 'let' and 'yield' require version opt-in. The site that used 'yield' has since been updated to avoid using 'yield'. So we could try again to reserve 'let' unconditionally. Heaven knows I've been yapping about 'let' as the new 'var' long enough to warn most developers away from it! I discussed this on IRC briefly with Oliver, who seemed game. The only issue I see is that nightly builds (WebKit, Chrome, Firefox) don't get enough use to do other than find true positives. It would be good to find such 'let' usage in the wild, of course, but finding nothing won't give us a green light, just lack of a red light. Why unconditionally reserve let? - would it not make more sense to handle this in a contextual fashion if we can do so? – if so, we could introduce 'let' without any backwards compatibility risk, and retain the option to promote it to a keyword at a later date. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 3:27 PM, Brendan Eich wrote: You're proposing that we require 'let' be only at the start of statements? If so, then destructuring is problematic: foo(); let [x] = y; Did that last line destructure the property named '0' of the object denoted by y into a let-bound x, or was it old, pre-ES6 code that stored y into the x'th element of an object denoted 'let'? In either case the 'let' is at the start of a statement. /be Based on the draft of the spec I have, I don't think that is an actual ambiguity here (albeit naming an array 'let' could be very confusing!). This could of course either be an error in my reading of the spec, or a bug in the current draft of the grammar. :-) The rules for destructuring give: ArrayBindingPattern : [ Elisionopt BindingRestElementopt ] [ BindingElementList , Elisionopt BindingRestElementopt ] Note the literal comma required after any BindingElementList - as I parse the grammar your example is not valid ES6, to destructure the first element from an array you would have to write: foo(); let [x,] = y; As such, the example you give could only be storing y to a property x of object let (or a syntax error in ES5-strict / ES6 modes). Is my reading of the spec incorrect here? Is this the intention? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote: On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: ArrayBindingPattern : [ Elisionopt BindingRestElementopt ] [ BindingElementList , Elisionopt BindingRestElementopt ] It's a grammar bug. Thanks for the proof reading... The final opt cited above is the bug, right? The first right-hand side still is enough to produce the [x] pattern. /be I assumed the bug was the presence of a literal comma? G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Ah, I see! - Thanks. On Jan 3, 2012, at 4:58 PM, Brendan Eich wrote: On Jan 3, 2012, at 4:50 PM, Gavin Barraclough wrote: On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote: On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: ArrayBindingPattern : [ Elisionopt BindingRestElementopt ] [ BindingElementList , Elisionopt BindingRestElementopt ] It's a grammar bug. Thanks for the proof reading... The final opt cited above is the bug, right? The first right-hand side still is enough to produce the [x] pattern. /be I assumed the bug was the presence of a literal comma? No, compare to ArrayLiteral: ArrayLiteral : // See 11.1.4 [ Elisionopt ] [ ElementList ] [ ElementList , Elisionopt ] ElementList : // See 11.1.4 Elisionopt AssignmentExpression ElementList , Elisionopt AssignmentExpression Replace ArrayLiteral with ArrayBindingPattern, ElementList with BindingElementList, and AssignmentExpression with BindingRestElement. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hey Dave,
I'm definitely in favour of removing the opt-in (or at least commonly removing
the need to opt-in), and support the goal of one JS. Since most of the new
syntax only relies on reserved words and, as Brendon stated, yield is only
valid in function* constructs, the only problem so far as new syntax is
concerned would seem to be `let`? Given how fundamental `var` is to writing a
program in JS, if we intend `let` to be the new `var` then it would be a huge
loss if this was the one new piece of syntax that wasn't available to all code.
Other than an ASI issue, which we can fix with a no-LineTerminator-here (as for
module), I think we can just treat `let` as a contextual keyword in classic
code, and it should be completely backwards compatible? I don't believe any
statement beginning with:
`let` Identifier
or
`let` {
could have been valid ES5 syntax anyway. The situation for:
`let` [
is a little more tricky, since this could be a property access expression,
however looking at the rules for ArrayBindingPattern it seems that this must
always either be empty, end with a comma, or end with a BindingRestElement? If
so, I don't think there is any pattern that will parse as both an
ArrayBindingPattern and an Expression.
(Am I reading ArrayBindingPattern correctly, and is this the intention? – the
rules for ArrayBindingPattern is a little confusing, since it allows:
[ BindingElementList `,` Elisionopt BindingRestElementopt ]
which appears to be a slightly verbose way of saying:
[ BindingElementList Elision BindingRestElementopt ]
and there is also similar language in BindingElementList).
One issue with allowing let statements in classic code is that classic code
also allows with statements, both constructs make use of the LexicalEnviroment,
and as I read it the current runtime semantics could give rise to some, um,
interesting behaviour! - but I wouldn't see this as a major concern.
If all new syntax is backwards compatible and enabled in all code then it
raises the question, how exactly would the language change inside of a module?
1) Would we implicitly enable ES5-strict mode inside modules?
2) Do we change the behaviour of typeof inside modules?
3) Do we change static scoping / access to the global object inside modules?
(Does this cover everything?)
It seems likely that there will be users of the language who will take existing
ES5 code, wrap it in module syntax, and expect this to work. If users do so,
it seems to me that:
* It would seem most desirable for existing ES5 code were to just work.
* Next best would be if certain constructs were to generate an early error,
making it impossible for a user to miss the compatibility issue.
* Less desirable would be for code moved into module to run without generating
early errors, but to potentially be able to generate new runtime errors.
* Least desirable would be for code moved into a module to continue to function
without throwing, but with subtly different runtime semantics.
# But then what about static scoping?
Compile-time checking of variables is a really important goal, and we don't
have to abandon it. We just do the checking only within module code, relative
to the current contents of the global object. This means it's still
technically possible for globals to disappear at runtime (and consequently
throw errors).
If I'm interpreting your proposal correctly then this would only result in new
early errors, which I think makes this a very transparent and understandable
change for developers – this seems like pure win.
The large majority of changes introduced by strict mode are new syntax errors,
so implicitly enabling strict mode seems reasonable, but I have some concern
about this – there are new runtime errors (albeit some would probably be
covered by your stricter static scoping semantics), and there is the change in
runtime behaviour for the handling of the this value.
Brendan's objection withstanding, I'm inclined to agree with you that we should
not change the semantics of typeof.
So my answers to my three questions above would be a hesitant yes, no, and yes
(per your static scoping proposal).
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Versioning?
As an aside (I'm not arguing for or against inline versioning here) isn't:
use version 6;
more backwards compatible?
For example, consider the following:
use version 6; with ({hi:Hi!}) alert(hi);
I believe this is a valid program in ES5, that treating use version 6 as a
directive would break?
Whereas I don't see how:
use version 6;
could currently be being parsed as valid ES5.
Obviously if we allowed use directives to be split across multiple lines then
ASI could be an issue, but so long as the syntax required:
use no-newline-here Identifer ...
then this form seems safer.
G.
On Dec 19, 2011, at 10:21 AM, Xavier MONTILLET wrote:
Why
use version 6;
and not
use version 6;
? Just to be sure ES 6 code breaks in old browsers ?
And what do you mean by opt-in for ES6 ? New syntax ? Everything in ES 6 ?
I'm thinking about weakmaps:
- on the one hand, you want to use native weakmaps when available so
you would want to opt-in for ES6
- but on the other hand, you could also implement a weakmap polyfill
that wouldnt be as efficient, that would suck the memory but still
work, and have it work in older browsers
Therefore, setting the thing to do to opt-in for ES6 to something
not backward compatible doesn't seem like a good idea to me.
On Mon, Dec 19, 2011 at 1:42 PM, David Bruant bruan...@gmail.com wrote:
I did start a related thread a while ago [1].
Brendan's response [2] explained a few things:
Please read RFC 4329:
http://tools.ietf.org/html/rfc4329
There will be *at least* a ;version=6 parameter you can use, probably
with either application/javascript and application/ecmascript -- I have
argued that we should align version numbers.
Beyond the RFC 4329 version= parameter, we also want a pragma for
in-script-content version assertion:
use version 6;
See the full response [2] for full context.
Besides an es-discuss thread, I think that what is really needed is an
harmony proposal. How to opt-in for ES6 is outside of the scope of pure
ECMAScript (especially if it's with playing with the HTML script tag
@type attribute), but let's face it, web devs need this information and
a wiki page on the topic would be handy.
At the time of reading Brendan's response, I didn't have anything to add
on that and I still don't. Unlike HTML and CSS, JavaScript needs new
syntax features. Syntax features that are NOT backward compatible with
ES3. If you use one of these features, your script break in older
browsers (unlike new HTML elements and CSS rules).
I don't see an alternative to versionning. Smarter people are welcome to
jump in, I guess.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-August/016262.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2011-August/016267.html
Le 19/12/2011 11:49, Peter van der Zee a écrit :
https://lists.webkit.org/pipermail/webkit-dev/2011-December/018924.html
``use version 6;``
In which thread on esdiscuss should I have read about that?
- peter
___
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
___
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
Exemplars static properties.
On Nov 14, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
Using object exemplars, the named abstraction is itself an instance of the
abstraction. Some people seem to be perfect happy to only have and use this
form of object abstraction. However, others prefer to think in a more
classical style where the named object representing an abstraction is a
distinct kind of object that is not itself an instance of the abstraction. In
practice, these two views of object abstraction are very closely related/
For example, a very simple addition to the above definition essentially turns
Point into a function exemplar. Function exemplars can also be thought of
as class exemplars:
let Point = {
x: 0,
y: 0,
constructor(x, y) {
this.x = x;
this.y = y;
}
}.constructor; //--- note added property reference
Apologies in advance if this has already been proposed, but I was looking at
the exemplar examples, and wondering if an additional small extension to object
literal syntax might provide a rather nice way to support 'static' (or class)
properties, per the ClassPropertyDefinition properties of the minimal classes
proposal. Could we permit dot notation to allow properties to be defined on
other properties already being defined within the literal? E.g.:
let o1 = {
o2: {
x: 1
}
o2.y: 2
};
This example would define an object o1 with one property, o2, which in turn
contains two properties, x y. I think this dot notation could be generally
useful in defining object literals, but it seems like it could be particularly
useful when defining exemplar objects since it would allow properties to be
defined on the constructor property, for example defining a function property
on the constructor:
let Point = {
x: 0,
y: 0,
constructor(x, y) {
this.x = x;
this.y = y;
},
constructor.fromPolar: function(radius, azimuth) {
return new Point(radius * Math.cos(azimuth), radius *
Math.sin(azimuth));
}
}.constructor;
let p = Point.fromPolar(Math.sqrt(2), Math.PI/4)
print(p.x, p.y);
If this dot notation could also be used when defining methods (functions
omitting the function keyword, as per the constructor method in the exemplars
example), and if these methods were to also have their prototype property set
to point to the containing object literal (again, as per the constructor
method), then it would also make it possible for methods to be defined with in
the intention of use with the 'new' keyword as alternative constructors for the
type, e.g.:
let Point = {
x: 0,
y: 0,
constructor(x, y) {
this.x = x;
this.y = y;
},
constructor.Polar(radius, azimuth) {
this.x = radius * Math.cos(azimuth);
this.y = radius * Math.sin(azimuth);
}
}.constructor;
let p = new Point.Polar(Math.sqrt(2), Math.PI/4)
print(p.x, p.y);
Further, if dot notation were also allowed in defining getter/setter properties
I believe it would make this syntax fully sufficient to define all types of
properties on the constructor as described in the ClassPropertyDefinition
grammar in the minimal classes proposal.
Any thoughts on this suggestion would be appreciated.
Many thanks happy thanksgiving!,
Gavin.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Nov 16 meeting notes
On Nov 16, 2011, at 5:19 PM, Waldemar Horwat wrote: Map/Set: Size property should be a getter property with no matching setter. It's defined on the property. What is its name? size, count, or length? Decide on es-discuss. Hi Waldemar, I'm unclear what It's defined on the property means, should this read It's defined on the prototype? thanks, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Regexp backreferences
Hi Paul, I tested this a while back, and I hit a couple of web sites using octal escapes in regexp literals (from memory gmail might have been one, and possibly old versions of jquery? - but I'm really not sure), I came to the conclusion that this wasn't going to fly. However our current octal implementation seems a little overly permissive, so I've been thinking about trying restricting these in JavaScriptCore in a couple of ways: 1) There is probably no need to support invalid numeric escapes that do not correspond to a single octal character in the range 0..255 (e.g. /\777/). We can probably generate early errors for values outside this range. This change would be a useful simplification since the currently implementation requires us to choose whether to spilt numeric escape based terms later in the regexp. E.g. consider the regexp /\39()()()...()()()/. The current behaviour is that the numeric escape my be treated as either one term (a backreference) or two terms (octal escape \3 and character 9), depending on how many subpattern captures follow it. It would be nice to remove this complexity. 2) Since octal escapes are not permitted in string literals in strict mode, it might be a good idea to prohibit them from regexp literals too. When parsing strict more code we could validate that regexp literals only contain valid numeric escapes. This could be something useful to incorporate into the spec, since we could explicitly define that this is only allowed in strict mode, as the spec already does for octal numeric literals escapes in strings - and any extension to support octal escapes in regexps would be a natural fit for annex B.1. On the topic of octal literals, there is something odd in the spec's current definition for octal escapes in string literals. Section B.1.2 currently defines: OctalEscapeSequence :: OctalDigit [lookahead is not DecimalDigit] ZeroToThree OctalDigit [lookahead is not DecimalDigit] FourToSeven OctalDigit ZeroToThree OctalDigit OctalDigit If I'm reading the spec correctly, the following string literals are valid: \4779 (equivalent to \x27 + 79) \3779 (equivalent to \xFF + 9) \479 (equivalent to \x27 + 9) But these are not: \379 \49 \39 For consistency I'd suggest revising the spec to either: OctalEscapeSequence :: OctalDigit [lookahead is not OctalDigit] ZeroToThree OctalDigit [lookahead is not OctalDigit] FourToSeven OctalDigit ZeroToThree OctalDigit OctalDigit or: OctalEscapeSequence :: OctalDigit [lookahead is not DecimalDigit] ZeroToThree OctalDigit [lookahead is not DecimalDigit] FourToSeven OctalDigit [lookahead is not DecimalDigit] ZeroToThree OctalDigit OctalDigit [lookahead is not DecimalDigit] I'd prefer the latter of the two options, since I think we could fairly cleanly define octal escape syntax for non-strict regexp literals to match this. cheers, G. On Aug 9, 2011, at 1:41 PM, Paul Biggar wrote: [apologies for the duplicate post on test262@, my first attempt bounced on es-discuss@] Hi folks, Currently in SpiderMonkey, overlarge regex backreferences do not cause syntax errors. We are considering making them cause syntax errors for test262 compliance, but are worried it will break the web. As far as I can tell, we inherited our behaviour from Apple's Yarr, which took the behaviour from us, who originally copied IE back when that was important. Chrome does the same as us. Does anyone have any idea or data as to whether this will break the web? If no such data exists, we can always just try it and see if it breaks things. Should this be removed form test262? Thanks, Paul Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=413155 test262 test cases: http://hg.ecmascript.org/tests/test262/file/034836894a85/test/suite/sputnik_converted/15_Native/15.10_RegExp_Objects/15.10.2_Pattern_Semantics/15.10.2.11_DecimalEscape/S15.10.2.11_A1_T2.js http://hg.ecmascript.org/tests/test262/file/034836894a85/test/suite/sputnik_converted/15_Native/15.10_RegExp_Objects/15.10.2_Pattern_Semantics/15.10.2.11_DecimalEscape/S15.10.2.11_A1_T3.js -- Paul Biggar Compiler Geek pbig...@mozilla.com @paulbiggar ___ test262-discuss mailing list test262-disc...@mozilla.org https://mail.mozilla.org/listinfo/test262-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
Might it be reasonable to make private properties be regular properties on the object, with a new 'private' attribute, similar to the existing writable/configurable attributes? From the perspective of code outside of the associated class, an instance's private property would be non-readable, non-writable and non-configurable (likely also non-enumerable?), with any attempt to get, set, or delete the property failing in a similar manner to an existing writable/configurable attribute violation. It would be great to hear your thoughts on this. See above -- private means you can't probe, let alone collide, for the private name from outside of the abstraction. Private name objects prove much more than a single-bit 'private' attribute -- they allow private, protected, friend, shared-secret, and public-but-guarnateed-unique names. /be Got it, cheers gents. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote: On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough barraclo...@apple.com wrote: Hi Mark, In the harmony classes proposal, http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in understanding the following issue: One or two namespaces for public properties and private instance variables [RESOLVED two, Mark’s argument] Do you remember if this argument was made in email, and if so would anyone happen to know where to look to find this (I've tried a little googling to no avail!), I'd be interested in understanding the rationale behind this decision. I don't think it was made in before in email. Here goes: For non-const classes, their instances are extensible by default. Even if you disagree with this default, I think we generally agree that there should at least be an option to make extensible instances. Say public and private share one namespace. Say extensible instance X has private instance property 'foo'. Say a client of X tries to extend it with a public 'foo' property. What happens? Ah, I see. It's a fair point, but isn't this already a hazard that the language faces? Suppose I have two objects, extensible instance X with private instance property 'foo', and extensible object Y upon which I have defined a property 'foo' using Object.defineProperty, setting writable=false. If a client of Y tries to extend if with a public 'foo' property, then this would fail (throwing a TypeError in strict mode code). Would it not be acceptable for the attempted assignment to the private property of X to fail in a similar fashion? It seems that it is already the case that if a client wishes to associate data with a given object under any arbitrary name, then the only truly safe way to do so is through an external mapping such as a weak map / ephemeron table? Might it be reasonable to make private properties be regular properties on the object, with a new 'private' attribute, similar to the existing writable/configurable attributes? From the perspective of code outside of the associated class, an instance's private property would be non-readable, non-writable and non-configurable (likely also non-enumerable?), with any attempt to get, set, or delete the property failing in a similar manner to an existing writable/configurable attribute violation. It would be great to hear your thoughts on this. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?
On Jul 7, 2011, at 2:40 PM, Lasse Reichstein wrote:
On Thu, 07 Jul 2011 21:17:17 +0200, Mike Samuel
One way to tell whether the group initialized to empty works on an
interpreter is to test
/^(?:\1x(y)x){2}$/.test(xyxyxyx)
which is true in most interpreters, but false in Rhino1.7 and Chrome12.
I do believe it should be false
Yep, this is our understanding too (and we agree with the same results).
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?
On Jul 7, 2011, at 2:59 PM, Mike Samuel wrote:
Agreed.
Would that mean that
/^(?:\1x(y)x){2}$/.test(xyxxyx) !/^(?:\1x(y)x){2}$/.test(xyxyxyx)
If so, V8 agrees with that, the species of monkey in FF 5 does not,
the JsCore in Safari 533.21 does not, and Rhino does.
Yes. This is fixed for Safari in the WebKit nightly builds.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Public/private namespaces in harmony classes proposal
Hi Mark, In the harmony classes proposal, http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in understanding the following issue: One or two namespaces for public properties and private instance variables [RESOLVED two, Mark’s argument] Do you remember if this argument was made in email, and if so would anyone happen to know where to look to find this (I've tried a little googling to no avail!), I'd be interested in understanding the rationale behind this decision. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Quasi-literals for templating?
Hi Mike,
I think there may be a bug in the desugaring. My understanding is that the
only arguments to the quasi tag are the call site id the SVE, and the SVE
contains only the substitution values, but in the desugaring example literal
portions are being passed to the quasiTag too:
quasiTag(unguessableId1234, literalPortion\0 , x, literalPortion1])
I think this should be:
quasiTag(unguessableId1234, x)
cheers,
G.
On Jun 15, 2011, at 5:49 PM, Mike Samuel wrote:
2011/6/15 Axel Rauschmayer a...@rauschma.de:
Quick feedback: I haven’t seen SVE (substitution value expression?) defined
anywhere and can’t find a description of using ${{var}} as syntactic sugar
for {var:${var}}.
SVE is defined in
http://wiki.ecmascript.org/doku.php?id=harmony:quasis#substitution_body_syntax
reproduced below:
SVE
Production Result
QuasiLiteral :: QuasiTag`LiteralPortion QuasiLiteralTail
SVE(QuasiLiteralTail)
QuasiLiteralTail :: Substitution LiteralPortion QuasiLiteralTail
array-concat(single-element-array(SVE(Substitution)),
SVE(QuasiLiteralTail))
QuasiLiteralTail :: ` an empty array
Substitution :: $Identifier PrimaryExpression : Identifier
Substitution :: ${SubstitutionModifier Identifier}PrimaryExpression
SubstitutionBody :: Identifier IdentifierPathTail MemberExpression :
str-concat(SV(Identifier), SV(IdentifierPathTail))
IdentifierPathTail :: .IdentifierName IdentifierPathTail
str-concat(“.”, SV(IdentifierName), SV(IdentifierPathTail))
IdentifierPathTail :: εthe empty string, ““
The SVE of a substitution is an expression that is evaluated in the
scope in which the quasiliteral appears. The SVE of the quasi literal
is the array of the SVE for each substitution.
E.g. the SVE of quasitag`literalPortion0 $x literalPortion1 $y.z
literalPortion2` is [x, y.z].
___
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: [Harmony classes] method lexical scope for InstancePropertyDefinitions, PrototypePropertyDefinitions?
On Jun 14, 2011, at 3:27 PM, Brendan Eich wrote:
On Jun 14, 2011, at 2:45 PM, Gavin Barraclough wrote:
return x * y * z;
This works for the public instance properties, but IIRC some folks object
that it is too easy to make mistakes vs. formal parameters of the same name.
Understood. It seems unfortunate to me to restrict the language syntax here to
dictate what really seems to be an open question of coding style. Choosing to
prefix all member property access with 'this.' in an attempt to avoid such
mistakes certainly seems a reasonable position for a programmer to take,
however I don't think it's clear that this is the only possible correct
decision. A devil's advocate argument might be that the unnecessary verbosity
this introduces may make the code less readable, and increase the difficulty
for a developer to spot bugs. I don't wish to start a debate on what the right
style is here; rather to suggest that we shouldn't be taking a position on
either side.
It would seem possible that if we stick with the current proposal and member
properties are not in lexical scope, then this may be something that would have
to be revisited in a later revision of the language, should developers report
the syntax to be overly verbose. If this is the route we go down, do you think
perhaps it might be worth trying to reserve space in the language such that
there would be room for backwards compatible changes here? For example, might
there be any value in considering poisoning these Identifiers, such that a
resolve of an Identifer matching the name of an instance property from inside a
method is a syntax error?
public weight()
{
return this.volume() * density;
}
Here's the killer. density is private. Yes, in this case there can be no
other density, but the Point equals method that needs to use p@x and p@y or
private(p).x and private(p).y to compare to the other (argument) point p must
have new notation for referring to the private instance variable of the other
maybe-instance.
Same if you had a compareDensity(otherBox) method here.
Given this, putting the private in scope is helpful for self-references but
not for other-refs, and it is a bit misleading.
Well, I guess there is a simple solution to that problem, though it introduces
an asymmetry that I'm not sure you'll be keen on. :-)
Within methods on classes, where ever the Identifier on the RHS of a dot access
MemberExpression matches the name of a private property defined in the class,
we could always assume this this will be a private property access. This would
allow private property access with no additional syntax. In cases where it is
necessary to access a public property on an object that has a name aliasing a
private member on the current class, bracket access syntax could be used (and a
programmer could chose to avoid this problem through naming conventions if they
wished to do so, e.g. prefix all private instance property names to prevent
conflicts with public properties).
On the topic of p@x, p@y, I find that syntax a little weird since the @ sign
reads backwards to me - with an @ I naturally expect the property to be on the
left, and the thing that owns it on the right. E.g. bren...@mozilla.com -
mozilla.com is an object that has a property called brendan. ;-)
Similarly, if prototype property definitions were brought into scope we could
omit the 'this.' on the call to volume:
public weight()
{
return volume() * density;
}
Object != scope. We do not want mutable objects on the scope chain. We don't
want any objects on the scope chain, really. This goes for modules too, they
are closed for a reason.
Just to clarify I'm only proposing bringing methods on the prototype into the
lexical scope of a method where they are defined in the class declaration with
a PrototypePropertyDefinition; this would be a purely lexical desugaring rather
than introducing the prototype object onto the scope chain.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Quasi-literals for templating?
On Jun 13, 2011, at 11:11 PM, Mike Samuel wrote:
Also, what is the 'this' object passed to the quasi handler? - might it make
sense for 'this' to be the site specific object, rather than the passing
this as an argument?
If the quasi handler is a member expression as in foo.bar`baz${boo}`
then this is the left operand of the member expression, foo in that
example.
this seems to make some logical sense, and makes the
Making the call-site object only available via `this` would prevent
bound methods from using it.
Ah! - that makes sense. It hadn't been obvious to me that this use case would
be possible, and I don't think there are any examples in the proposal showing
this - if you have a chance, I think it could be great to add an example to
demonstrate this.
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Quasi-literals for templating?
On Jun 12, 2011, at 4:35 AM, Axel Rauschmayer wrote:
BTW: “Desugaring” at the beginning of “Semantics” seems mangled.
I was just about to hit send an email saying the same thing!
Also, the section on the default quasi tag the name expandedLP is used, where I
think this should be unescapedLP?
On this topic, rawLP and unescapedLP seem to be poor names. 'LP' seems to be
meaningless line noise to developers using the feature who are not familiar
with the grammar in the spec (and should not need to be). Maybe these could
just raw unescaped? - or rawLiterals/rawLiteralPortion/etc for something more
verbose?
Has that been considered as a use case (e.g. after a compilation/generation
step?). But it doesn’t seem like identifier names are accessible to quasi
handlers, which would make this difficult.
This too! Given the example for the proposal:
msg`Welcome to ${siteName}, you are visitor number ${visitorNumber}!`
It would seem useful if the same quasi could handle both of these formatting
tasks:
msg`Welcome to ${siteName}, you are visitor number ${visitorNumber}!`
msg`Welcome, you are visitor number ${visitorNumber} to ${siteName}!`
And it seems the identifiers could help. Presumably the identifier names could
be stored in a new frozen array on the call site specific object? Might it
also be useful to provide a mechanism to override the identifier with something
clearer, for example, if the visitor number were being read from the property
'obj().x',
msg`Welcome to ${siteName}, you are visitor number ${visitorNumber:
obj().x}!`
Also, what is the 'this' object passed to the quasi handler? - might it make
sense for 'this' to be the site specific object, rather than the passing this
as an argument? - this seems to make some logical sense, and makes the
arguments passed to function simpler to comprehend - they are all the
substitution values, and arguments.length now matches the number of
substitutions, indexed from zero, rather than being arguments length - 1. E.g.
the first example in the proposal:
// hoisted declaration.
const callSiteId1234 = {
rawLP: ['quasiLiteralPart1 ', ' quasiLiteralPart2'],
unescapedLP: ['quasiLiteralPart1 ', ' quasiLiteralPart2']
};
// in-situ
quasiHandlerName(callSiteId1234, quasiSubstitution)
would instead call:
// in-situ
quasiHandlerName.call(callSiteId1234, quasiSubstitution)
cheers,
G.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
Brendan, Out of interest was a C++/Java style constructor considered, with the constructor name matching the class name? cheers, Gavin. On May 16, 2011, at 8:02 AM, Brendan Eich wrote: On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote: On 16.05.2011 10:49, Brendan Eich wrote: On May 15, 2011, at 10:01 PM, Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues This looks pretty good at a glance, but it's a lot, and it's new. Looking closer, I have to say something non-nit-picky that looks bad and smells like committee: http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#inheritance Two kinds of inheritance, depending on the dynamic type of the result of evaluating the //MemberExpression// on the right of ''extends''? That will be confusing. Is the traits-composition way really needed in this proposal? If so, then please consider not abuse ''extends'' to mean ''compose'' depending on dynamic type of result of expression to its right. Some simple examples of all use-cases would are needed I think. Regarding `new` keyword for the constructor (aka initializer), after all, it als may be OK. E.g. Ruby uses `new` as exactly the method of a class -- Array.new, Object.new, etc. Though, `constructor` is also good yeah. My point is not to bikeshed, rather (a) to name existing prototype properties minimally, (b) to avoid preempting other names. Good, bad, or in between, the prototypal pattern in JS for constructor C binds C.prototype.constructorr to C. It does not bind C.prototype.new. Regarding two inheritance types, I think better to make nevertheless one inheritance type -- linear (by prototype chain). And to make additionally small reusable code units -- mixins or traits -- no matter. Thus, of course if they will also be delegation-based and not just copy-own-properties, then we automatically get a sort of multiple inheritance. Self has multiple prototypes and you can use them for all kinds of inheritance patterns. Parents are Shared Parts... Organizing programs without classes Delegation-based mixins though can be implemented as a library using proxies (example: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/mixin.js, implementation: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/mixin.js, notice I also used Object.new :)). Proxies are too costly, though. They always have a handler full of traps. The idea with classes is to capture prototypal inheritance as used today. The idea with traits is to make composition flexible, with fast failure on conflict and tools to rename around conflicts. Putting classes and traitts together should be doable but it shouldn't use the same sytnax (extends) and it shouldn't require proxies. /be ___ 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: I noted some open issues on Classes with Trait Composition
Cheers Brendan. I must say, I really like how the class sugar is coming together. It seems that more closely matching a familiar syntax might make things a little more approachable for existing OO programmers, but I certainly see the elegance in using constructor directly. thanks, G. On Jun 7, 2011, at 12:57 PM, Brendan Eich wrote: I'm not sure -- I wasn't in on the earlier design sessions among the champions. I know new was used, but if we are sugaring prototypal inheritance, we need something to create constructor in the prototype (which is where method definitions written directly in the class body bind their names). Having some backstage magic wire up constructor is possible but then you have two names for the constructor. That is a wart. The bigger issue is that doing this preempts use of new as a prototype property name (allowed by ES5). So to keep things simple, express the prototypal machinery already in the language directly and explicitly, and avoid preempting new, we've settled on constructor. The bigger issues with classes to close down include private instance variable syntax and semantics, and static method ss. Some followup work is already under way here. We need to get this solid by the July TC39 meeting. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default non-capturing regex flag [WAS: how to create strawman proposals?]
Actually this is fixed in ToT WebKit, have closed the stale bug. https://bugs.webkit.org/show_bug.cgi?id=56041 cheers, G. On Jun 5, 2011, at 5:04 PM, Juriy Zaytsev wrote: On Sun, Jun 5, 2011 at 5:30 PM, Brendan Eich bren...@mozilla.com wrote: On Jun 3, 2011, at 10:49 AM, Juriy Zaytsev wrote: Chrome (13) and Safari (5) tolerate n. No error. Bugs filed? WebKit bug — https://bugs.webkit.org/show_bug.cgi?id=41614 Seems to be stalled. cc'ing Oliver. -- kangax ___ 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: LOG10E mystery constant
Hi Mark, I've fixed this value for Safari in WebKit r79246. cheers, G. On Feb 20, 2011, at 10:04 PM, Mark S. Miller wrote: That's what I needed. Thanks. On Sun, Feb 20, 2011 at 9:53 PM, Rico Wind ri...@google.com wrote: This was recently fixed in V8, see: http://code.google.com/p/chromium/issues/detail?id=72555 Cheers, Rico On Feb 21, 2011 6:47 AM, Mark S. Miller erig...@google.com wrote: On Sun, Feb 20, 2011 at 9:26 PM, John Cowan co...@mercury.ccil.org wrote: Mark S. Miller scripsit: This is the only constant whose actual value differs across browsers: 0.43429448190325176 v8 version 2.3.9 [console: dumb] 0.4342944819032518 Chrome 11.0.672.2 dev [etc.] The two values are really the same value when represented as an IEEE double. The difference is in the printing routine, not the internal representation. Specifically, the ...2518 browsers are rounding, the ...25176 browsers are not. But they convert to back to two different floating point numbers, at least on all the browsers I quickly tried. 0.43429448190325176 === 0.4342944819032518 false 0.43429448190325176 0.4342944819032518 true 0.43429448190325176 0.4342944819032518 false A little more testing reveals that the two numbers seem to be consecutive, in the sense that there are no intermediate representable numbers. Floating-point numbers are a little like sandpiles; every time you pick one up, you get a little less sand and a little more dirt. (But this is not true of integers up to 2^53, slightly less than 10^16. -- John Cowan co...@ccil.org Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. --Calvin, giving Newton's First Law in his own words -- Cheers, --MarkM -- Cheers, --MarkM ___ 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: Additional syntax - B.1.2 String Literals
Hi Geoffrey, Apologies, I had missed your earlier mail to the list – please consider my last post a wholehearted agreement. I hope we can get some traction on on this, for my part I'll try to continue to try to producing some of the additional language we may need in appendix B, in the hope this can help move things forwards. cheers, G. On Dec 28, 2010, at 11:53 PM, Geoffrey Sneddon wrote: On 29/12/10 02:56, Gavin Barraclough wrote: Hi, In the definition of OctalEscapeSequence, and in the accompanying semantics, it is required at numerous points that the subsequent character is not a DecimalDigit: OctalEscapeSequence :: OctalDigit [lookahead ∉ DecimalDigit] ZeroToThree OctalDigit [lookahead ∉ DecimalDigit] FourToSeven OctalDigit ZeroToThree OctalDigit OctalDigit In these cases it would seem to make more sense to require that the subsequent character is not an OctalDigit. For example, implementations supporting this additional syntax the string literal \019 is permitted (with '\01' matching the rule 'ZeroToThree OctalDigit'). As such, I think throughout B.1.2. it would make more sense to replace DecimalDigit with OctalDigit. Additionally, I believe it would also be helpful to redefine the following rule (in section B.1.2): EscapeCharacter :: SingleEscapeCharacter DecimalDigit x u Again, replacing DecimalDigit with OctalDigit. This would add documentation reflecting the fact that in addition to permitting octal escapes implementations commonly permit '\8\ and '\9' to be handled as NonEscapeCharacter sequences in string literals. This has been raised on the list before, most recently at https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003490.html. Also, with regards to that, see https://mail.mozilla.org/pipermail/es-discuss/2010-November/012168.html. (I'll follow up on that sometime soon!). -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/ ___ 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: RegExp syntax suggestion: allow CharacterClassEscape in CharacterRange
Hi Lasse,
Thank you for the comprehensive list!
In all these cases we should perhaps first attempt to determine whether these
could just be considered spec compliance issues that ought to be fixed in
implementations. If retaining compatibility with existing code is going to
require continued support for syntax beyond that currently covered by the spec,
then it would seem beneficial to try to add this. I'd be interested in
discussing some proposals to address the issues you've listed.
On Dec 9, 2010, at 12:33 PM, Lasse Reichstein wrote:
// Invalid ControlEscape/IdentityEscape character treated as literal.
/\z/; // Invalid escape, same as /z/
To match the current behavior, IdentityEscape shouldn't exclude all of
IdentifierPart,
but only the characters that already mean something else.
Agreed - I expect this change will be necessary to retain compatibility with
existing code. String literals define all source characters not used in escape
sequences - bar decimal digits - to be valid identity escapes
(NonEscapeCharacter), so it would only seem consistent to do the same for
RegExps. A minimal but slightly messy fix would be:
IdentityEscape :: SourceCharacter but not DecimalDigit nor ControlEscape nor
CharacterClassEscape nor any of:
b B c x u
ClassEscape ::
DecimalEscape
b
B
CharacterEscape
CharacterClassEscape
Adding semantics such that ClassEscape :: B generates the character set { B }.
A slightly cleaner solution may be to restructure this bit of BNF to give
ClassEscapes and AtomEscapes separate copies of IdentityEscape such that
special handling for /[\B]/ is not necessary:
AtomEscape ::
DecimalEscape
CharacterEscape
CharacterClassEscape
AtomIdentityEscape
AtomIdentityEscape :: SourceCharacter but not DecimalDigit nor ControlEscape
nor CharacterClassEscape nor any of:
b B c x u
CharacterEscape ::
ControlEscape
c ControlLetter
HexEscapeSequence
UnicodeEscapeSequence
ClassEscape ::
DecimalEscape
b
CharacterEscape
CharacterClassEscape
ClassIdentityEscape
ClassIdentityEscape :: SourceCharacter but not DecimalDigit nor ControlEscape
nor CharacterClassEscape nor any of:
b c x u
Even if we did not need to liberalize IdentityEscape to this extent, the
current definition in the spec seems a little unworkable, particularly since it
appears to prohibit /\$/. Defining IdentityEscape in terms of IdentifierPart
also appears to have the consequence of requiring users to remember which set
of punctuation falls within the UnicodeConnectorPunctuation set to correctly
determine which punctuation marks they can validly escape this way! I would
suggest a still restrictive, but more practical, definition for IdentityEscape
would be:
IdentityEscape ::
SourceCharacter but not ControlLetter or DecimalDigit
// Incomplete/Invalid ControlEscape treated as either \\c or c
/\c/; // same as /c/ or /\\c/
/\c2/; // same as /c2/ or /\\c2/
// Incomplete HexEscapeSequence escape treated as either \\x or x.
/\x/; // incomplete x-escape
/\x1/; // incomplete x-escape
/\x1z/; // incomplete x-escape
// Incomplete UnicodeEscapeSequence escape treated as either \\u or u.
/\u/; // incomplete u-escape
/\uz/; // incomplete u-escape
/\u1/; // incomplete u-escape
/\u1z/; // incomplete u-escape
/\u12/; // incomplete u-escape
/\u12z/; // incomplete u-escape
/\u123/; // incomplete u-escape
/\u123z/; // incomplete u-escape
Most of the RegExps treat a malformed (start of a multi-character) escape
sequence
as a simple identity escape or octal escape, and extends identity escapes to
all characters
that doesn't already have another meaning (ControlEscape,
CharacterClassEscape or
one of c, x, u, or b, and B outside a CharacterClass).
Agreed - though I think it would be preferable to try generating the syntax
error in these cases, if this is feasible.
Given that these invalid sequences are currently being handled with some
inconsistency across browsers, this might a good hint that we can treat this as
a compliance bug that we can just fix in implementations. Hex and unicode
escapes are also present in string literals, and malformed escapes in string
literals should also generate a syntax error (browser behaviour appears
inconsistent here), and it would seem preferable to retain consistency between
string RegExp literals.
If we do need to be permissive in these cases, then I guess this requires up to
four characters of lookahead. I believe invalid escapes - if not a syntax
error - should be handled as per IdentityEscapes (i.e. the backslash is not
retained - /\c/ as /c/, not /\\c/).
Allowing /\c2/ to match c2, but requiring /\CB/ to match \x02 seems like
it would
be better explained in prose than in the BNF.
Well, if we're going to allow /\c2/ to match c2 then it
Additional syntax - B.1.2 String Literals
Hi, In the definition of OctalEscapeSequence, and in the accompanying semantics, it is required at numerous points that the subsequent character is not a DecimalDigit: OctalEscapeSequence :: OctalDigit [lookahead ∉ DecimalDigit] ZeroToThree OctalDigit [lookahead ∉ DecimalDigit] FourToSeven OctalDigit ZeroToThree OctalDigit OctalDigit In these cases it would seem to make more sense to require that the subsequent character is not an OctalDigit. For example, implementations supporting this additional syntax the string literal \019 is permitted (with '\01' matching the rule 'ZeroToThree OctalDigit'). As such, I think throughout B.1.2. it would make more sense to replace DecimalDigit with OctalDigit. Additionally, I believe it would also be helpful to redefine the following rule (in section B.1.2): EscapeCharacter :: SingleEscapeCharacter DecimalDigit x u Again, replacing DecimalDigit with OctalDigit. This would add documentation reflecting the fact that in addition to permitting octal escapes implementations commonly permit '\8\ and '\9' to be handled as NonEscapeCharacter sequences in string literals. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RegExp syntax suggestion: allow CharacterClassEscape in CharacterRange
According to the ES5 spec a regular expression such as /[\w-_]/ should generate a syntax error. Unfortunately there appears to be a significant quantity of existing code that will break if this behavior is implemented (I have been experimenting with bringing WebKit's RegExp implementation into closer conformance to the spec), and looking at other implementations it appears common for this error to be ignored. The parsing of this expression matches a single NonemptyClassRanges of the form ClassAtom - ClassAtom, where the first ClassAtom is a CharacterClassEscape and the second a SourceCharacter. Per section 15.10.2.15 of the spec this calls CharacterRange, resulting in this syntax error: 1. If A does not contain exactly one character or B does not contain exactly one character then throw a SyntaxError exception. I'd like to propose a minimal change to hopefully allow implementations to come into line with the spec, without breaking the web. I'd suggest changing the first step of CharacterRange to instead read: 1. If A does not contain exactly one character or B does not contain exactly one character then create a CharSet AB containing the union of the CharSets A and B, and return the union of CharSet AB and the CharSet containing the one character -. This is roughly equivalent to implicitly escaping the hyphen in any invalid range*, so /[\w-_]/ is treated as /[\w\-_]/. I believe this change would have a low impact on the spec, that it should be feasible for implementors to easily adopt this behavior, and that this should commonly be compatible with existing code that is currently not spec compliant. many thanks, Gavin [ * However this is not exactly equivalent to treating the hyphen in an invalid ranges as having being escaped. Consider /[\d-a-z]/. Escaping the hyphen in the invalid range would give the expression /[\d\-a-z]/, in which case a-z would be matched as a CharacterRange. This would arguably be a more intuitive interpretation of the expression, but changing the language to match this would require a more intrusive change to the grammar, which I'm assuming would not be desirable. ] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
