Re: Existential operator (was: ||= is much needed?)
Brendan Eich wrote: Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesses could be solved very cleanly and consistently. No, because (a) the overhead of a new object is too high; (b) with any kind of suffix-? or suffix-.? as you proposed it would be observable that you get a new object instead of short-circuiting to undefined -- the new object is exposed in the language. What's wrong with it per se? Let it be exposed, let people use it. Some of uses will be wrong, they will eventually die, some of them will be fine, they survive (no need to add keyword or API for it, null.? yields it and it is usably short). And BTW, if foo.? is too long and abuse of dot, you can use for example postfix tilde to get foo~.bar, foo.bar~(), bar in foo~ etc. /be Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Brendan Eich wrote: Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesses could be solved very cleanly and consistently. No, because (a) the overhead of a new object is too high; (b) with any Spec / impl overhead or memory / perf overhead? Because the latter is of little worries, common uses of foo.? like foo.?.bar can be of course shortcut without using [[NullPatternObject]] at all. Herby kind of suffix-? or suffix-.? as you proposed it would be observable that you get a new object instead of short-circuiting to undefined -- the new object is exposed in the language. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
On Jun 21, 2012, at 3:22, Herby Vojčík he...@mailbox.sk wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
I feel there is objection to introduce magical [[NullPatternObject]]
into language, but all of CS-style soft-accesses could be solved very
cleanly and consistently.
No, because (a) the overhead of a new object is too high; (b) with any
kind of suffix-? or suffix-.? as you proposed it would be observable
that you get a new object instead of short-circuiting to undefined --
the new object is exposed in the language.
What's wrong with it per se? Let it be exposed, let people use it. Some of
uses will be wrong, they will eventually die, some of them will be fine, they
survive (no need to add keyword or API for it, null.? yields it and it is
usably short).
And BTW, if foo.? is too long and abuse of dot, you can use for example
postfix tilde to get foo~.bar, foo.bar~(), bar in foo~ etc.
/be
Herby
Language-level support for the null object pattern would be pretty excellent! I
think, given the CoffeeScript grep stats (not to mention common `options =
options || {}` code), people are definitely using ? in that capacity. The
possibility of introducing something elegant like this seems like exactly why
getting in only property-access ?. would be a mistake.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default iterator
On Wed, Jun 20, 2012 at 11:37 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
In our previous discussion I had come to the understanding that the
default iterator would use a private name. The main benefit for using
a private name is to not pollute the property name space.
Can you give an example of code that would be harmed by this pollution?
It's not pollution to add a useful method to Array.prototype. ES5 added several.
If this was the ordinary property, iterator, it might break existing
code that already use iterator in some other way.
var obj = LibraryX.getObject();
obj.iterator().forEach(...);
This code won't break.
If anything the new proposal makes it easier to change LibraryX to
support iteration: just add a suitable next() method to its iterator
object.
It also breaks objects as maps since any string can be used as key.
Again, please give an example of code that would break.
Note that the decision was already made that there would not be an
iterator method on Object.prototype, so objects-as-maps will be
iterated using a helper function:
var obj = JSON.parse(data);
import keys, items from '@iter';
for (let k of keys(obj)) { ... }
for (let [k, v] of items(obj)) { ... }
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Return values from callbacks?
Hello Hackers, If there was a easy way to wrap an asynchronous in a synchronous API would it not be easy? Because we can wrap it that way any API will need to accept a callback to return proceed values. I bit be speaking absolute non sense here, but just felt something like that might makes things easier, while I was coding THIShttps://github.com/hemanth/node-rsj/commit/051c6c45c15e2cebc88dae20b28ffe3335823335 -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Return values from callbacks?
See dherman's http://taskjs.org/ for one way that ES6 will support, but which requires expliciti 'yield' usage when you wrap to make the preemption point clear. /be Hemanth H.M wrote: Hello Hackers, If there was a easy way to wrap an asynchronous in a synchronous API would it not be easy? Because we can wrap it that way any API will need to accept a callback to return proceed values. I bit be speaking absolute non sense here, but just felt something like that might makes things easier, while I was coding THIS https://github.com/hemanth/node-rsj/commit/051c6c45c15e2cebc88dae20b28ffe3335823335 -- /'I am what I am because of who we all are'/ h3manth.com http://www.h3manth.com /-- Hemanth HM/ ___ 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: Return values from callbacks?
WOW! Ok, thank you. On Thu, Jun 21, 2012 at 8:32 PM, Brendan Eich bren...@mozilla.org wrote: See dherman's http://taskjs.org/ for one way that ES6 will support, but which requires expliciti 'yield' usage when you wrap to make the preemption point clear. /be Hemanth H.M wrote: Hello Hackers, If there was a easy way to wrap an asynchronous in a synchronous API would it not be easy? Because we can wrap it that way any API will need to accept a callback to return proceed values. I bit be speaking absolute non sense here, but just felt something like that might makes things easier, while I was coding THIS https://github.com/hemanth/**node-rsj/commit/** 051c6c45c15e2cebc88dae20b28ffe**3335823335https://github.com/hemanth/node-rsj/commit/051c6c45c15e2cebc88dae20b28ffe3335823335 -- /'I am what I am because of who we all are'/ h3manth.com http://www.h3manth.com /-- Hemanth HM/ __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
So do you have to do it by treating the ?. operator as a standalone? Instead, could you do the indefinte soak part during parsing, treating the rest of the expression differently after having seen a ?. operator? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
John Tamplin wrote: So do you have to do it by treating the ?. operator as a standalone? Not sure what you mean here -- standalone ? (with an English-langauge ? implied after in your sentence? ;-)? Or something else that amounts to a concealed Reference or Nil-value-proxy expression? Just talking spec here: as Allen mentioned, ECMA-262 specifies semantics by evaluating productions in a mostly-LR(1) grammar, so member and call expressions (left-associative) have to result in some kind of (spec-internal or language-external) value. Thus foo?.bar.baz.quux is really (((foo?.bar).baz).quux). Instead, could you do the indefinte soak part during parsing, treating the rest of the expression differently after having seen a ?. operator? Indeed one can translate when parsing. CoffeeScript does this, with some separate passes for its other purposes (implicitly declared variables, indentation-based block structure, etc.). The ES specs can't do this, though, not without a total rewrite. /be -- John A. Tamplin Software Engineer (GWT), Google ___ 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: Existential operator (was: ||= is much needed?)
Brendan Eich wrote: Thus foo?.bar.baz.quux is really (((foo?.bar).baz).quux). So (as many have noted) parenthesization does not call GetValue in ECMA-262: 11.1.6 The Grouping Operator The production PrimaryExpression : ( Expression ) is evaluated as follows: 1. Return the result of evaluating Expression. This may be of type Reference. NOTE This algorithm does not apply GetValue to the result of evaluating Expression. The principal motivation for this is so that operators such as delete and typeof may be applied to parenthesised expressions /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
On Thu, Jun 21, 2012 at 11:23 AM, Brendan Eich bren...@mozilla.org wrote: John Tamplin wrote: So do you have to do it by treating the ?. operator as a standalone? Not sure what you mean here -- standalone ? (with an English-langauge ? implied after in your sentence? ;-)? Or something else that amounts to a concealed Reference or Nil-value-proxy expression? Just talking spec here: as Allen mentioned, ECMA-262 specifies semantics by evaluating productions in a mostly-LR(1) grammar, so member and call expressions (left-associative) have to result in some kind of (spec-internal or language-external) value. Thus foo?.bar.baz.quux is really (((foo?.bar).baz).quux). Yes, and I am suggesting during parsing it gets treated as: (((foo?.bar)?.baz)?.quux) because we saw a ?. operator earlier in the expression. That way you don't have to get the Coffeescript behavior by introducing some fake object or a MaybeReference, and you just implement the ?. operator as always returning the LHS if it is null/undef. Indeed one can translate when parsing. CoffeeScript does this, with some separate passes for its other purposes (implicitly declared variables, indentation-based block structure, etc.). The ES specs can't do this, though, not without a total rewrite. I realize it would be changes, but then so would adding a MaybeReference. Just thought I would bring it up. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
John Tamplin wrote:
On Thu, Jun 21, 2012 at 11:23 AM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
John Tamplin wrote:
So do you have to do it by treating the ?. operator as a
standalone?
Not sure what you mean here -- standalone ? (with an
English-langauge ? implied after in your sentence? ;-)?
Or something else that amounts to a concealed Reference or
Nil-value-proxy expression?
Just talking spec here: as Allen mentioned, ECMA-262 specifies
semantics by evaluating productions in a mostly-LR(1) grammar, so
member and call expressions (left-associative) have to result in
some kind of (spec-internal or language-external) value.
Thus foo?.bar.baz.quux is really (((foo?.bar).baz).quux).
Yes, and I am suggesting during parsing it gets treated as:
(((foo?.bar)?.baz)?.quux)
because we saw a ?. operator earlier in the expression.
Ok, but this doesn't seem observable, or necessary in the spec.
That way you don't have to get the Coffeescript behavior by
introducing some fake object or a MaybeReference,
CoffeeScript does not introduce a fake object or MaybeReference:
$ cat /tmp/soak.coffee
o = null
console.log(o?.p.q.r.s.t)
$ ./bin/coffee -p !$
./bin/coffee -p /tmp/soak.coffee
(function() {
var o;
o = null;
console.log(o != null ? o.p.q.r.s.t : void 0);
}).call(this);
Rather, ECMA-262 would need to elaborate its internal Reference type as
Allen wrote.
and you just implement the ?. operator as always returning the LHS if
it is null/undef.
Note also that CoffeeScript does not short-circuit to the
unbound/null/undefined LHS value, it always uses void 0 -- AKA undefined.
Indeed one can translate when parsing. CoffeeScript does this,
with some separate passes for its other purposes (implicitly
declared variables, indentation-based block structure, etc.).
The ES specs can't do this, though, not without a total rewrite.
I realize it would be changes, but then so would adding a
MaybeReference. Just thought I would bring it up.
Allen's right, MaybeReference is a much (much!) smaller change,
especially if we want to support the ?( and suffix-? variants.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Brendan Eich wrote:
Replying to both Herby and Domenic here.
Domenic Denicola wrote:
On Jun 21, 2012, at 3:22, Herby Vojčíkhe...@mailbox.sk wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
I feel there is objection to introduce magical [[NullPatternObject]]
into language, but all of CS-style soft-accesses could be solved very
cleanly and consistently.
No, because (a) the overhead of a new object is too high; (b) with any
kind of suffix-? or suffix-.? as you proposed it would be observable
that you get a new object instead of short-circuiting to undefined --
the new object is exposed in the language.
What's wrong with it per se?
1. The overhead, which is not wanted in almost all cases. Then saying
implementations may optimize simply makes a de-facto standard with
high implementation cost inevitable. We should normatively spec what
CoffeeScript does -- boolean result for suffix-? or anything like it --
or else add a singleton Nil object that can be reused.
2. It's not what CoffeeScript does.
3. For foo?.bar if foo is not bound or has null or undefined value, if I
understand correctly, you propose to use ({}) instead. This does not
provide indefinite soak, where foo?.bar.baz.quux silently
short-circuits to undefined value on unbound or ==-null foo. And if
Object.prototype.bar exists, foo?.bar where foo is unbound/==-null will
wrongly evaluate to Object.prototype.bar's value.
4. Likewise foo?(bar) or however it might be spelled will try to invoke
an empty fresh object, throwing a TypeError -- not what we want.
5. if (foo.?) as Herby proposed evaluates to a truthy fresh object if
foo is unbound or has ==-null value. CoffeeScript and any sane
interpretation of suffix-? or variant spelling wants falsy if not false
result for unbound/==-null foo.
These are problems _per se_. But see below on the Nil singleton idea.
Let it be exposed, let people use it. Some of uses will be wrong,
they will eventually die, some of them will be fine, they survive (no
need to add keyword or API for it, null.? yields it and it is usably
short).
And BTW, if foo.? is too long and abuse of dot, you can use for
example postfix tilde to get foo~.bar, foo.bar~(), bar in foo~ etc.
/be
Herby
Language-level support for the null object pattern would be pretty
excellent!
Depends on what you mean by null object.
I don't believe anyone wants a fresh empty object for each ? ?. ?( or
however we spell the variants. There's no evidence for this from
CoffeeScript. A fresh object as default value breaks indefinite soak and
may expose proto-properties (3), breaks the ?( call variant (4), and
breaks boolean tests of suffix-? expressions (5), as far as I can tell.
I think, given the CoffeeScript grep stats (not to mention common
`options = options || {}` code), people are definitely using ? in that
capacity.
Sure, no one argues otherwise. The minority use-cases could wait, but we
should discuss them before deferring. Agree with all that. But a Null
object meaning fresh empty object is no solution, per (1-5) above.
The possibility of introducing something elegant like this seems like
exactly why getting in only property-access ?. would be a mistake.
What is elegant may be something you haven't actually described: a Nil
singleton, a proxy actually, which can soak up indefinite gets, sets,
and calls. It must be a singleton to avoid the overhead problem.
Adn that is precisely what I proposed under name [[NullPatternObject]].
So all of (1), (3), (4) and (5) are void.
This Nil proxy would take the place of the concealed Reference type that
Allen suggested. It has some appeal to fans of Smalltalk who message nil.
Smalltalk nil is a bit different from Null Pattern. I proposed Null
pattern (optimized off when not actually needed in the equation, but
exposed when needed).
Such a Nil proxy still cannot masquerade as false, though, and that is
required for suffix-? testing. An object that can convert to false
awaits value objects
(http://wiki.ecmascript.org/doku.php?id=strawman:value_objects) married
with proxies to make value proxies.
Such a [[NullPattternObject]] can ToBoolean to false. No problem I see.
I've argued in the past against coupling proposals and chaining risk of
non-acceptance, so I don't think the existential operator and variants
should depend on such a Nil proxy singleton idea. Happy to discuss it
more, but as a practical matter I would want it concealed in
http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator and
exposed only in a separate proposal, once we have value objects and
value proxies (assuming we get them).
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Announcing, June 15, 2012 ES6 Draft
Hi Allen, The section on Module Declaration Instantiation (10.5.2) is currently empty. Is this because the modules spec is still in flux? Is it reasonable to assume that modules are still on the table for es6? jas -- Jasvir Nagra On Fri, Jun 15, 2012 at 8:28 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: Download it from: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes from May TC39 Review - Tentative addition of Class Definitions Syntax and Semantics in 13.5 based upon Maximally Minimal Strawman. *NOTE-Classes do not yet have full consensus within TC39 and may not survive.* - 11.1.5 make super references illegal in method definitions within object literals - removed | and TriangleLiterals - reverted methods to only have bracketed function bodies rather than concise bodies - Removed Object.isObject - Removed String.prototype.toArray - Eliminated requirement for buggy daylight savings time adjustment Other changes - 5.1.1 , 5.2 Defined “chain production” and implicit algorithm pass through for chain productions. Eliminated unnecessary pass through algorithms - Eliminate final remnants of ES1 line number references within algorithm conventions - Moved Literal from lexical to syntactic grammar - Updated keywords list - 10.1.2 /10.4 introduce concept of non-ECMAScript functions and execution contexts for them - 11.1.4.2 tweaks to Array Comprehension syntax - made it an early error to use a reserved word as a single identifier property definition shorthand - added default value initializers to internal elements and properties of destructuring assignment patterns - corrected major case statement semantic bug from ES5.1 - made YieldExpressions illegal in parameter default value initializers - made home object binding of methods contingent upon them actually referencing super - added [[ThisMode]] internal property to functions via FunctionCreate to deal with lexical this binding in arrow functions - made super references and yield expressions early errors in ProgramBody - In Math.sign clarified handling of -0 - Added String.prototype HTML wrapping functions to Annex B - Merged ES5.2 Annex F into Annex DE - Made Annex F an Informative Summary of Static Semantic algorithms - Fixed bugs 340,351-354,356,358-361,364-367,369-376,378-380,382,384-38 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Herby Vojčík wrote:
Adn that is precisely what I proposed under name
[[NullPatternObject]]. So all of (1), (3), (4) and (5) are void.
Apologies, I missed that and saw only someone (perhaps it was Domenic)
write ({}) as the default value, which is not the same.
Such a Nil proxy still cannot masquerade as false, though, and that is
required for suffix-? testing. An object that can convert to false
awaits value objects
(http://wiki.ecmascript.org/doku.php?id=strawman:value_objects) married
with proxies to make value proxies.
Such a [[NullPattternObject]] can ToBoolean to false. No problem I see.
You're right we could hardcode a special case in ToBoolean ahead of
value objects.
To prevent this object from escaping into the language, we would need a
special case in GetValue too. That makes this equvalent to Allen's
conditional Reference (MaybeReference). Or were you thinking of letting
this magic singleton esape into the language?
If so, I think you'll get serious push-back on TC39. Escaping raises the
ante quite a bit. We have to be sure a falsy object won't confuse some
code (SES code in particular) in a way that could lead to an exploit.
Apart from SES-focused concerns, letting the magic reference-like type
escape exposes something ahead of schedule, before value objects in
particular. If there's no need to let this thing escape, then we
sholudn't. And in that case it's equivalent to MaybeReference.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Announcing, June 15, 2012 ES6 Draft
Jasvir Nagra wrote: The section on Module Declaration Instantiation (10.5.2) is currently empty. Is this because the modules spec is still in flux? Is it reasonable to assume that modules are still on the table for es6? Modules are definitely in ES6. The draft is incomplete, of course. Should be complete in terms of syntax and semantics by end of year. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
private name methods ?
Hi, Some time ago I tried to get your intention about clojure protocols as I see them as better fit for JS and it's runtime than currently proposed classes. Although I can see that they may have implied too much new semantics. Recently I realized that private name objects can be used to do most of what protocols do with some boilerplate performance penalties: https://gist.github.com/2967124 I was wondering if it's a good idea to adjust private name objects proposal, since IMO it solves some of the ergonomics related issues that would prevent it from taking off: API for calling private named methods is awkward: object[method](foo, bar) With private name methods it's natural: method(object, foo, bar) API for accessing private names is ugly in comparison to normal properties: var data = object[secret] With private methods it can be more natural: var data = secret(object) Private methods can provide not only more natural API (that feels similar to one used today), but there is much more to it, private methods provide semantics very similar to clojure protocols (https://vimeo.com/11236603) that arguably enable interesting ways to do polymorphism (http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post) that IMO fits much better JS runtime than proposed classes. It is also fully harmonious with JS prototypical inheritance. It also solves issues inherent with diversity of community and libraries, as on may define protocol through the set of methods that can be independently implemented for set of libraries used. For example event dispatching protocol may be defined via on, off, emit private methods that later can be implemented without any conflict risks for DOM, jQuery, Backbone, etc... This will allowing one to use same set of privates methods regardless of which library data structure comes from. In a way monkey patching on ste roids an d conflict risks! Thanks for you time I'm looking forward to your feedback! -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: private name methods ?
I get few comments on twitter regarding this:
So the idea is that a private name object is callable,
and name(obj, ...rest) delegates to obj[name](...rest)?
Yeah thats is a primary idea:
name(object, …rest) = object[name](…rest)
Although my hope is that `null` and `undefined` could also be supported in some
way.
Note that with following will work only if `object` is from the same JS context
(iframe):
Object.prototype[name] = function() { … }
name(object)
Hopefully `name` implementation for `null` would enable it for objects from
other contexts as well.
In addition I have proposed that `name` would just return property if it's not
a function:
name(object, …rest) = typeof(object[name]) === 'function' ?
object[name](…rest) : object[name]
Which pot pretty negative feedback:
It overlaps and precludes the case where you just want to get the function
without calling.
As a matter of fact I outlined the primary case where this feature is very
helpful in the gist:
Watchable.prototype[watchers] = function(target) {
return target[watchers] = []
}
This enables lazy initialization of private properties that otherwise would
have required second private
name. While I find this use case quite compelling I see drawbacks as well.
Never the less I think that
even without the last feature callable private names are pretty compelling.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Thursday, 2012-06-21 at 11:54 , Irakli Gozalishvili wrote:
Hi,
Some time ago I tried to get your intention about clojure protocols as I see
them as better fit for JS and it's runtime than currently proposed classes.
Although I can see that they may have implied too much new semantics.
Recently I realized that private name objects can be used to do most of what
protocols do with some boilerplate performance penalties:
https://gist.github.com/2967124
I was wondering if it's a good idea to adjust private name objects
proposal, since IMO it solves some of the ergonomics related issues that
would prevent it from taking off:
API for calling private named methods is awkward:
object[method](foo, bar)
With private name methods it's natural:
method(object, foo, bar)
API for accessing private names is ugly in comparison to normal properties:
var data = object[secret]
With private methods it can be more natural:
var data = secret(object)
Private methods can provide not only more natural API (that feels similar to
one used today), but there is much more to it, private methods provide
semantics very similar to clojure protocols (https://vimeo.com/11236603) that
arguably enable interesting ways to do polymorphism
(http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post)
that IMO fits much better JS runtime than proposed classes. It is also fully
harmonious with JS prototypical inheritance. It also solves issues inherent
with diversity of community and libraries, as on may define protocol through
the set of methods that can be independently implemented for set of libraries
used. For example event dispatching protocol may be defined via on, off, emit
private methods that later can be implemented without any conflict risks for
DOM, jQuery, Backbone, etc... This will allowing one to use same set of
privates methods regardless of which library data structure comes from. In a
way monkey patching on steroids and conflict risks!
Thanks for you time I'm looking forward to your feedback!
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Brendan Eich wrote:
Herby Vojčík wrote:
Adn that is precisely what I proposed under name
[[NullPatternObject]]. So all of (1), (3), (4) and (5) are void.
Apologies, I missed that and saw only someone (perhaps it was Domenic)
write ({}) as the default value, which is not the same.
Such a Nil proxy still cannot masquerade as false, though, and that is
required for suffix-? testing. An object that can convert to false
awaits value objects
(http://wiki.ecmascript.org/doku.php?id=strawman:value_objects) married
with proxies to make value proxies.
Such a [[NullPattternObject]] can ToBoolean to false. No problem I see.
You're right we could hardcode a special case in ToBoolean ahead of
value objects.
To prevent this object from escaping into the language, we would need a
special case in GetValue too. That makes this equvalent to Allen's
conditional Reference (MaybeReference). Or were you thinking of letting
this magic singleton esape into the language?
Definitely. It brings all pros of Null Pattern there (all of the uses I
included in previous posts, automatically and consistently).
When it is explicit, users can begin to use it willingly. It may bring
previously hard-to-get solutions.
If so, I think you'll get serious push-back on TC39. Escaping raises the
ante quite a bit. We have to be sure a falsy object won't confuse some
code (SES code in particular) in a way that could lead to an exploit.
That I cannot envision... but Null Pattern object that produces itself
for all operations ([[Get]], [[Call]], ...) should not be problematic.
Apart from SES-focused concerns, letting the magic reference-like type
escape exposes something ahead of schedule, before value objects in
particular. If there's no need to let this thing escape, then we
sholudn't. And in that case it's equivalent to MaybeReference.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Announcing, June 15, 2012 ES6 Draft
There are many things that are not yet in the spec. yet. It is still a work in progress. The harmony proposal page[1] generally is the plan of record for what is ultimately expected to be in the spec. Allen [1] http://wiki.ecmascript.org/doku.php?id=harmony:proposals On Jun 21, 2012, at 11:29 AM, Jasvir Nagra wrote: Hi Allen, The section on Module Declaration Instantiation (10.5.2) is currently empty. Is this because the modules spec is still in flux? Is it reasonable to assume that modules are still on the table for es6? jas -- Jasvir Nagra On Fri, Jun 15, 2012 at 8:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Download it from: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes from May TC39 Review Tentative addition of Class Definitions Syntax and Semantics in 13.5 based upon Maximally Minimal Strawman. NOTE-Classes do not yet have full consensus within TC39 and may not survive. 11.1.5 make super references illegal in method definitions within object literals removed | and TriangleLiterals reverted methods to only have bracketed function bodies rather than concise bodies Removed Object.isObject Removed String.prototype.toArray Eliminated requirement for buggy daylight savings time adjustment Other changes 5.1.1 , 5.2 Defined “chain production” and implicit algorithm pass through for chain productions. Eliminated unnecessary pass through algorithms Eliminate final remnants of ES1 line number references within algorithm conventions Moved Literal from lexical to syntactic grammar Updated keywords list 10.1.2 /10.4 introduce concept of non-ECMAScript functions and execution contexts for them 11.1.4.2 tweaks to Array Comprehension syntax made it an early error to use a reserved word as a single identifier property definition shorthand added default value initializers to internal elements and properties of destructuring assignment patterns corrected major case statement semantic bug from ES5.1 made YieldExpressions illegal in parameter default value initializers made home object binding of methods contingent upon them actually referencing super added [[ThisMode]] internal property to functions via FunctionCreate to deal with lexical this binding in arrow functions made super references and yield expressions early errors in ProgramBody In Math.sign clarified handling of -0 Added String.prototype HTML wrapping functions to Annex B Merged ES5.2 Annex F into Annex DE Made Annex F an Informative Summary of Static Semantic algorithms Fixed bugs 340,351-354,356,358-361,364-367,369-376,378-380,382,384-38 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Announcing, June 15, 2012 ES6 Draft
Awesome. Thanks. -- Jasvir Nagra On Thu, Jun 21, 2012 at 1:16 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: There are many things that are not yet in the spec. yet. It is still a work in progress. The harmony proposal page[1] generally is the plan of record for what is ultimately expected to be in the spec. Allen [1] http://wiki.ecmascript.org/doku.php?id=harmony:proposals On Jun 21, 2012, at 11:29 AM, Jasvir Nagra wrote: Hi Allen, The section on Module Declaration Instantiation (10.5.2) is currently empty. Is this because the modules spec is still in flux? Is it reasonable to assume that modules are still on the table for es6? jas -- Jasvir Nagra On Fri, Jun 15, 2012 at 8:28 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: Download it from: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes from May TC39 Review - Tentative addition of Class Definitions Syntax and Semantics in 13.5 based upon Maximally Minimal Strawman. *NOTE-Classes do not yet have full consensus within TC39 and may not survive.* - 11.1.5 make super references illegal in method definitions within object literals - removed | and TriangleLiterals - reverted methods to only have bracketed function bodies rather than concise bodies - Removed Object.isObject - Removed String.prototype.toArray - Eliminated requirement for buggy daylight savings time adjustment Other changes - 5.1.1 , 5.2 Defined “chain production” and implicit algorithm pass through for chain productions. Eliminated unnecessary pass through algorithms - Eliminate final remnants of ES1 line number references within algorithm conventions - Moved Literal from lexical to syntactic grammar - Updated keywords list - 10.1.2 /10.4 introduce concept of non-ECMAScript functions and execution contexts for them - 11.1.4.2 tweaks to Array Comprehension syntax - made it an early error to use a reserved word as a single identifier property definition shorthand - added default value initializers to internal elements and properties of destructuring assignment patterns - corrected major case statement semantic bug from ES5.1 - made YieldExpressions illegal in parameter default value initializers - made home object binding of methods contingent upon them actually referencing super - added [[ThisMode]] internal property to functions via FunctionCreate to deal with lexical this binding in arrow functions - made super references and yield expressions early errors in ProgramBody - In Math.sign clarified handling of -0 - Added String.prototype HTML wrapping functions to Annex B - Merged ES5.2 Annex F into Annex DE - Made Annex F an Informative Summary of Static Semantic algorithms - Fixed bugs 340,351-354,356,358-361,364-367,369-376,378-380,382,384-38 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Herby Vojčík wrote: That I cannot envision... but Null Pattern object that produces itself for all operations ([[Get]], [[Call]], ...) should not be problematic. You might be surprised (I am) by how seemingly innocent things can become problematic. Just on aesthetic grounds, I bet TC39ers will react to this the way we react to document.all that masquerades as undefined. BTW, Pattern and Null are both not good words to join to name this thing. A pattern matching strawman exists, wherein patterns are special forms, built from destructuring patterns, used in certain syntactic forms but not first-class objects. And Null is to close to null and the ECMA-262 internal Null type. As a Unix hacker I can dig the /dev/null reference, if there is one, but it's too far afield. I do think Smalltalk's nil, even though not identical, suggests a better name. If we were to expose this singleton, we could do worse than call it something the Nil object. But I'm not sold on exposing it. Allen (and Mark if he has time) should weigh in. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Feedback on Subclassing Built-in Constructors
On Jun 21, 2012, at 8:48 AM, David Bruant wrote:
Hi,
I have read the recent Subclassing Built-in Constructors page [1] and I
have some feedback.
Well, that page is still is work in progress. But you feedback is still
appreciated.
This page exhibits a distinction that wasn't clear in my mind before reading
it: some internal properties can be added lazily like the ones for dates
while some (essential internal methods) cannot.
Yes, but mainly for implementation reasons. At least of the essential internal
properties are used so frequently that their implementation must be highly
optimized. Lazy updates to them may still be possible but are likely to have
deep implementation impacts with performance implications.
class MyDate extends Date {
constructor(...args) {
// |this| has no internal date property
super();
// now it does have them and can be considered as a date object,
[[NativeBrand]] aside
}
}
For constructor of objects that only add internal data properties and
additional internal method (like RegExps [[Match]]), this can work fine.
However, for objects with different essential internal methods, it cannot
work.
Now you're into the part of the document I haven't finished editing...
class MyArray extends Array {
constructor(...args){
// |this| not an array until i've called super(), right?
'length' in this; // false
this[2] = yo;
this.length = 1; // ? I guess nothing happens except that |this|
has a new 'length' property?
super(); // If nothing serious happens, the array invariant is
broken.
this[2] // ?
this.length // ?
}
}
I don't think there is a way out unless |this| is already an array in which
case 'super' is useless.
Well, the validity of any invariants over MyArray are actually the
responsibility of its implementors. But, if Array's constructor is defined
carefully generally things happen. Remember there is actually nothing special
about the 'length' property of an Array. It's the array [[DefineOwnProperty]]
internal method is special. One of the things it does is delete array elements
when the value of 'length' is decreased. So for the above scenario if Array
constructor was defined with these steps:
1 Set the [[DefineOwnProperty]] internal method of the this value to the
special array version.
2 Call the [[Put]] internal method of the this object with arguments
'length' and 0.
3 ...
at step 2 ([[Put]] actually delegates to [[DefineOwnPropety]] ) any elements
between 0 and the current length would get deleted and the length would set to
0. That would still leave element 2 around, but that element would be ignore
by any other array processing algorithms that depend upon length. Note that
it is already possible for an Array to inherit numerically indexed properties
whose indices are beyond the array length so there is no invariant that all
visible array index properties keys are within the length bounds.
But, in this case, I think the main thing is that we can't prevent developers
from coding crap. If they do, it really is their problem as long is we
guarantee memory safety.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Brendan Eich wrote: Herby Vojčík wrote: That I cannot envision... but Null Pattern object that produces itself for all operations ([[Get]], [[Call]], ...) should not be problematic. You might be surprised (I am) by how seemingly innocent things can become problematic. Just on aesthetic grounds, I bet TC39ers will react to this the way we react to document.all that masquerades as undefined. BTW, Pattern and Null are both not good words to join to name this I just named it on the grounds of the (non-GoF) design pattern which is called Null Object or Null Pattern, if I am not mistaken. But of course naming is not that important. thing. A pattern matching strawman exists, wherein patterns are special forms, built from destructuring patterns, used in certain syntactic forms but not first-class objects. And Null is to close to null and the ECMA-262 internal Null type. As a Unix hacker I can dig the /dev/null reference, if there is one, but it's too far afield. I do think Smalltalk's nil, even though not identical, suggests a better name. If we were to expose this singleton, we could do worse than call it something the Nil object. But I'm not sold on exposing it. Allen (and Mark if he has time) should weigh in. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Normalization and canonical equivalence in string comparison
I'm afraid it's not quite so simple. The Internationalization API spec defines localeCompare() as a wrapper around Intl.Collator.prototype.compare, so to make normalization mandatory for localeCompare, we'd have to make it mandatory for Collator as well. I'd like to get some input from implementors whether that makes sense, or whether they're planning to implement canonical equivalence in some other way. Thanks, Norbert On Jun 19, 2012, at 10:37 , Gillam, Richard wrote: Norbert-- The ECMAScript Internationalization API Specification currently has normalization as an optional feature in collation. However, it requires that the compare function return 0 when comparing Strings that are considered canonically equivalent by the Unicode standard. Canonical equivalence, I thought, is usually implemented through normalization. Does it make sense to keep normalization as a separate and optional feature then? Is anybody planning to implement canonical equivalence through other mechanisms, such that the lack of normalization would be visible in the comparison of non-equivalent strings? For what little it may be worth, I think it would make sense to just make normalization mandatory in localeCompare(). Of course, I don't know if that causes trouble for anybody (I'm pretty sure it doesn't for me). --Rich Gillam Lab126 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
I guess the grep work is not easy to do, but I have tried (manually) to find ?. or ?( in coffee script projects, trying to seek into projects of main contributors. Maybe not lucky or not really aware of the most popular projects, but I did not find any up to now. According to my previous posts I am quite convinced it has an interest, I remain perplex regarding the use of ?( , then, I am really curious to see CS's uses, could you please highlight some projects ? Le 21/06/2012 05:54, Jeremy Ashkenas a écrit : As requested, running those rough greps again on the top ten most popular CoffeeScript repos on Github yields: 188 uses of object?.property 32 uses of object?[key] 50 uses of function?(args) 46 uses of variable ?= value ... and the other ones are a bit tricker to grep for. There are at least a handful more uses of the `function?(args)` style but with implicit parentheses: `function? arg1, arg2` ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default iterator
On Jun 20, 2012, at 9:37 PM, Erik Arvidsson wrote: Jason Orendorff updated the iterator proposal a bit. Thank you Jason. I'd like to point out an issue with it though. In our previous discussion I had come to the understanding that the default iterator would use a private name. The main benefit for using a private name is to not pollute the property name space. Well, the ES6 spec. draft uses a private name, so I don't know if editing the wiki proposal will have any effect :-) If somebody things the spec should change there probably should have a bug filed against it and a subsequent discussion. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Internationalization: NaN and Infinity in date formatting
The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Internationalization: NaN and Infinity in date formatting
I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@norbertlindenberg.com] Sent: Thursday, June 21, 2012 4:23 PM To: es-discuss Subject: Internationalization: NaN and Infinity in date formatting The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ 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: Internationalization: NaN and Infinity in date formatting
Eric Albright wrote: I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. Agreed. /be From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@norbertlindenberg.com] Sent: Thursday, June 21, 2012 4:23 PM To: es-discuss Subject: Internationalization: NaN and Infinity in date formatting The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ 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
