Re: JavaScript 2015?
Whenever you mention revolutionary calendar I'm reminded of subsidized time in Infinite Jest. ES Year of Dairy Products from the American Heartland anyone? :) On Thu, Jan 22, 2015 at 5:35 PM, Brendan Eich bren...@mozilla.org wrote: The annuals idea was agreeable to TC39ers a recent meetings. Whether and how we cut over was not decided, in my view. Rushing to the new revolutionary calendar would be a mistake. We (TC39) need to cash checks we've written, and not with our body :-P. /be Angus Croll wrote: Name names. Who's idea was this? :) On Thu, Jan 22, 2015 at 4:53 PM, Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de wrote: That would be my preferred solution: the name affects book covers, domains, content, etc. = a significant amount of time and money. Even worse than renaming ES6 now would be renaming it later, though. On 23 Jan 2015, at 01:44, Arthur Stolyar nekr.fab...@gmail.com mailto:nekr.fab...@gmail.com wrote: Can we leave ES6 to ES6 because it's already here and call ES7 -- ES2016? Since ES7 not here yet and there are not much mentions of it. 2015-01-23 2:39 GMT+02:00 Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org: Andrea Giammarchi wrote: I particularly don't like the idea that things could be dropped or rushed last minute just because the new years eve is coming ... this feel like those stories with tight deadlines where management could easily fail due over-expectations on all possible 3rd parts alignment ( you know, like those 12 different JS engines out there + spartans ) No last minute slips -- that's a schedule-chicken outcome (where the cars do not collide but one veers and drives off a cliff!). The new stuff has to board its release train or its champions and fans will be sad, and perhaps take a credibility hit. This doesn't mean larger work must be broken down into too many pieces, but that is a risk. Larger work that can track across multiple years is always risky -- in my experience it very often aims for a target near Alpha Centauri at sublight speed, when the real action was over at Tau Ceti due to an FTL breakthrough, but no one knew at first that (a) FTL was possible; or (b) the Centauri systems were uninhabitable. If you get what I mean ;-). (Spartan uses Chakra, last I heard.) Mature projects can do rapid-er release more easily than young ones, for sure. I recall 4.2BSD Unix, then 4.3, and a bit of 4.4. I do like the idea of having more frequent rolling releases, but yet I don't know why year-naming would be the choice. Does the name matter? You seemed to be objecting on more substantive grounds. Don't back off to mere quibbling about labels! Anyway, please consider keeping ES6 exactly ES6, we will have time to align the ESX where X = previous ESX +2009 concept. to Doctor Alex, at this point I think you should really stick with ES6 or avoid the ES at all and use JS 2015 This reminds me: Axel (not Alex) cannot recommend JavaScript 2015 to anything near the Ecma standard, because trademark. :-/ /be -- @nekrtemplar https://twitter.com/nekrtemplar -- Dr. Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de rauschma.de http://rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
Name names. Who's idea was this? :) On Thu, Jan 22, 2015 at 4:53 PM, Axel Rauschmayer a...@rauschma.de wrote: That would be my preferred solution: the name affects book covers, domains, content, etc. = a significant amount of time and money. Even worse than renaming ES6 now would be renaming it later, though. On 23 Jan 2015, at 01:44, Arthur Stolyar nekr.fab...@gmail.com wrote: Can we leave ES6 to ES6 because it's already here and call ES7 -- ES2016? Since ES7 not here yet and there are not much mentions of it. 2015-01-23 2:39 GMT+02:00 Brendan Eich bren...@mozilla.org: Andrea Giammarchi wrote: I particularly don't like the idea that things could be dropped or rushed last minute just because the new years eve is coming ... this feel like those stories with tight deadlines where management could easily fail due over-expectations on all possible 3rd parts alignment ( you know, like those 12 different JS engines out there + spartans ) No last minute slips -- that's a schedule-chicken outcome (where the cars do not collide but one veers and drives off a cliff!). The new stuff has to board its release train or its champions and fans will be sad, and perhaps take a credibility hit. This doesn't mean larger work must be broken down into too many pieces, but that is a risk. Larger work that can track across multiple years is always risky -- in my experience it very often aims for a target near Alpha Centauri at sublight speed, when the real action was over at Tau Ceti due to an FTL breakthrough, but no one knew at first that (a) FTL was possible; or (b) the Centauri systems were uninhabitable. If you get what I mean ;-). (Spartan uses Chakra, last I heard.) Mature projects can do rapid-er release more easily than young ones, for sure. I recall 4.2BSD Unix, then 4.3, and a bit of 4.4. I do like the idea of having more frequent rolling releases, but yet I don't know why year-naming would be the choice. Does the name matter? You seemed to be objecting on more substantive grounds. Don't back off to mere quibbling about labels! Anyway, please consider keeping ES6 exactly ES6, we will have time to align the ESX where X = previous ESX +2009 concept. to Doctor Alex, at this point I think you should really stick with ES6 or avoid the ES at all and use JS 2015 This reminds me: Axel (not Alex) cannot recommend JavaScript 2015 to anything near the Ecma standard, because trademark. :-/ /be -- @nekrtemplar https://twitter.com/nekrtemplar -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ 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: Object.assign with several source objects
the alternative is that the second argument expects an array of 1 to n
source objects. This works with reduce and leaves way clear for future 3rd
argument (eg deep copy boolean)
On Tue, Dec 17, 2013 at 5:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
true ... as true is for anything that will ever be passed to reduce that
accept just 2 arguments. Handy in a way, blocking progress in others.
`Object.assing(target, ...[multSources]);`
wins to me
On Tue, Dec 17, 2013 at 5:20 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Interestingly, if multiple arguments are not added now, they may never be
possible, since there will be so much `[a, b, c].reduce(Object.assign)`
code in the wild that implicitly passes an index as the third parameter and
the whole array as the fourth parameter.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Brendan Eich
Sent: Tuesday, December 17, 2013 20:18
To: Claude Pache
Cc: es-discuss
Subject: Re: Object.assign with several source objects
It's now or never. I agree multiple sources are useful enough to do now;
I don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
/be
Claude Pache mailto:claude.pa...@gmail.com December 17, 2013 5:06 PM
Hello,
Tonight, when playing with ES6's new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2),
...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) { var params = Object.assign({
method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
-Claude
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Should String.prototype.split accept variable arguments optionally?
with the separate arguments solution the 'limit' argument is unusable with the array solution you have a punctuation nightmare the required regex seems easier in comparison On Wed, Oct 16, 2013 at 5:54 AM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: Splitting by one value or another seems to be a pretty common use case if Stack Overflow questions and personal experience are an indication. For example - and and /. Currently, the solution is to pass a regular expression to String.prototype.split . However, it would be nice to be able to pass variable arguments to the method. So if I want to split strings like 0-12-12 and 321+32/14 or TI-CK ER instead of having to do: ``` myString.split(/ |-|\/|\+/g); // this is no fun to read myString.split( ,-,/,+); // this is easier myString.split([ ,-,/,+]); // this is also easier. ``` The advantage of the second one (accepting an Array) is that it does not require additional handling of the second limit parameter. A possible advantage of the first one is that it's simpler. The algorithm for the second one could be quite simple, in 21.1.3.17 only _SplitMatch_ needs to be updated, and implementation sounds pretty simple in engines and the semantics simple in the spec. Some other languages: - C# accepts an array of `char` or array of string in its Split, http://msdn.microsoft.com/en-us/library/tabh47cf.aspx - Ruby doesn't do this with `.split`, behaves like JS http://ruby-doc.org/core-2.0.0/String.html#method-i-split - Java String.split only accepts a regex - Python doesn't do this with `.split` Advantages: - Nice api addition that solves a common use case. - A way to split by multiple delimiters easily without knowledge of regular expressions. - Does not break the existing API, especially if we use array syntax. Disadvantages - Extra overhead - Use case needs assertion (Reminds me of stuff in string_extras http://wiki.ecmascript.org/doku.php?id=harmony:string_extras ) What do you think? ___ 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: has the syntax for proxies been finalized ?
Great info thanks (and Tom and Domenic)
A note on MDN confirming that direct proxy adhered to the new spec (and a
similar one on old proxy saying it didn't) would probably be immensely helpful
to other people who had the same question I had.
Also (to all) deleting or marking as obsolete all wiki-harmony docs that no
longer meet the standard would save a lot of wasted hours
thanks!
On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6 standard
The latest official news is in the May 2013 TC39 notes:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies
The final design of proxies is the direct proxies design. As Tom said, a
proxy is now created doing:
var p = Proxy(target, handler)
Proxy.create and Proxy.createFunction are aimed at disappearing.
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support the
Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
On the SpiderMonkey (Gecko implements the DOM and other platform APIs and
SpiderMonkey is the part that implement ECMAScript) side, I filed a bug to
get rid of these as it's indeed confusing to have both APIs exposed in web
pages:
https://bugzilla.mozilla.org/show_bug.cgi?id=892903
IIRC, the V8 team had started implementing something (behind a flag), and
then wars on Proxy design happened, so they chose to wait for the design to
stabilize. Now may be a good time to restart
However MDN calls the above the 'Old Proxy API'.
I'm glad I succeeded in, at least, making people wonder what that was all
about :-)
Since I've been following closely the design of proxies, I documented them on
MDN. Especially after the implementation of direct proxies in Firefox
(where I moved the documentation of the previous API to its own page and try
to explain the best I could that people should not use it). I'm happy to
improve the doc if something isn't clear (on the feature itself or
clarify the current technico-social mess of different APIs in the wild).
As a side note, to my knowledge, the only native implementation of direct
proxies is in Firefox, but it's incomplete and has known bugs. You can
see the known limitations and bugs here:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_resolved=1
(depends on section. Bug 787710 is particularly funny :-)).
If you want to play with proxies, I think that the most faithful-to-the-spec
implementation is Tom's polyfill:
https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where he's
using the old API where available to implement the new one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
I can confirm:
npm install harmony-reflect
node --harmony
require('harmony-reflect')
and I'm good to go with ES6 proxy syntax
thanks all!
@angustweets
On Fri, Oct 18, 2013 at 7:49 AM, Angus Croll anguscr...@gmail.com wrote:
Great info thanks (and Tom and Domenic)
A note on MDN confirming that direct proxy adhered to the new spec (and a
similar one on old proxy saying it didn't) would probably be immensely
helpful to other people who had the same question I had.
Also (to all) deleting or marking as obsolete all wiki-harmony docs that
no longer meet the standard would save a lot of wasted hours
thanks!
On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6
standard
The latest official news is in the May 2013 TC39 notes:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies
The final design of proxies is the direct proxies design. As Tom said, a
proxy is now created doing:
var p = Proxy(target, handler)
Proxy.create and Proxy.createFunction are aimed at disappearing.
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
On the SpiderMonkey (Gecko implements the DOM and other platform APIs and
SpiderMonkey is the part that implement ECMAScript) side, I filed a bug to
get rid of these as it's indeed confusing to have both APIs exposed in web
pages:
https://bugzilla.mozilla.org/show_bug.cgi?id=892903
IIRC, the V8 team had started implementing something (behind a flag), and
then wars on Proxy design happened, so they chose to wait for the design to
stabilize. Now may be a good time to restart
However MDN calls the above the 'Old Proxy API'.
I'm glad I succeeded in, at least, making people wonder what that was all
about :-)
Since I've been following closely the design of proxies, I documented them
on MDN. Especially after the implementation of direct proxies in Firefox
(where I moved the documentation of the previous API to its own page and
try to explain the best I could that people should not use it). I'm happy
to improve the doc if something isn't clear (on the feature itself or
clarify the current technico-social mess of different APIs in the wild).
As a side note, to my knowledge, the only native implementation of direct
proxies is in Firefox, but it's incomplete and has known bugs. You can see
the known limitations and bugs here:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_resolved=1(depends
on section. Bug 787710 is particularly funny :-)).
If you want to play with proxies, I think that the most
faithful-to-the-spec implementation is Tom's polyfill:
https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where
he's using the old API where available to implement the new one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
No worries guys - thanks for adding the 'obsolete' note @angustweets On Fri, Oct 18, 2013 at 8:13 AM, Rick Waldron waldron.r...@gmail.comwrote: On Fri, Oct 18, 2013 at 10:53 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus Croll [anguscr...@gmail.com Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours @Angus, I'm sorry this happened, I try to keep up with marking wiki docs' status as best as I can. I know Rick has already made strides in that direction via warnings like This API is superseded by the newer direct proxies API. or This proposal has progressed to the Draft ECMAScript 6 Specification (Sept. 2013 draft Sections 9.3 and 26.2), which is available for review here: specification_drafts. Any new issues relating to them should be filed as bugs at http://bugs.ecmascript.org. The content on this page is for historic record only and may no longer reflect the current state of the feature described within. But I somewhat agree that the warnings are not scary enough. Something drastic like moving the entire page to obsolete:proxies would be nice. But, eh, broken links :-/. I'm all for suggestions to make it _even_ _more_ _clear_, as long as those suggestions don't break links (as Domenic has mentioned here). Currently, the old proxy proposals are stricken on the harmony:proposals page and the direct proxies proposal includes the progressed to draft text. FWIW, I've added The content on this page is OBSOLETE to the three oldest proxy proposals. @Tom - since you know the status of the more recent Proxy wiki pages better than I do, would you mind adding the same h1 text to those that fit the description of obsolete? Thanks! Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
@angustweets
On Fri, Oct 18, 2013 at 12:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Proxy.create and Proxy.createFunction are deprecated.
The correct syntax is `new Proxy(target, handler)`
In my original direct proxies proposal, the `new` was optional, so that
`var p = Proxy(target, handler)` works equally well (cf.
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies)
Since then, it seems people want to move away from implicit construction
(since it doesn't interact well with class inheritance), so I don't know if
there is still consensus on this.
In the prototype Firefox implementation, `new` is currently mandatory.
Regards,
Tom
2013/10/18 Angus Croll anguscr...@gmail.com
I couldn't find a commitment to a specific syntax in the latest ES6
standard
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
However MDN calls the above the 'Old Proxy API'.
Gecko also supports what MDN indicates implies is the current Proxy
syntax (i.e. new Proxy)
e.g.
var p = new Proxy(
{},
{get: function(p,x) {
return 'Hello ' + x
}}
);
p.World; //'Hello World'
Which is right?
thanks
@angustweets
___
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: has the syntax for proxies been finalized ?
thanks André that works!
(I was going by
https://github.com/tvcutsem/harmony-reflect/blob/master/doc/traps.md which
says 'delete')
@angustweets
On Fri, Oct 18, 2013 at 9:38 AM, André Bargull andre.barg...@udo.eduwrote:
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
The trap name for the `delete` operator is deleteProperty instead of
delete...
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
has the syntax for proxies been finalized ?
I couldn't find a commitment to a specific syntax in the latest ES6
standard
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
However MDN calls the above the 'Old Proxy API'.
Gecko also supports what MDN indicates implies is the current Proxy syntax
(i.e. new Proxy)
e.g.
var p = new Proxy(
{},
{get: function(p,x) {
return 'Hello ' + x
}}
);
p.World; //'Hello World'
Which is right?
thanks
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set to Array conversions
Thanks - I missed the obvious one I guess - though it still returns an
empty array in continuum and traceur.
e.g
[...(new Set([1,2,3])].length; //0
or
var s = new Set();
s.add('a');
s.add('b');
[...s].length; //0
assuming they just need to catch up
@angustweets
On Mon, Sep 16, 2013 at 8:42 AM, Claude Pache claude.pa...@gmail.comwrote:
I suggest:
[ ... mySet ]
or, if you don't want to use any new syntax:
Array.from(mySet)
—Claude
P.S. The syntax `[e for e of mySet]` is outdated in Harmony, you should
use `[(for let e of mySet) e]`.
Le 16 sept. 2013 à 17:33, Angus Croll anguscr...@gmail.com a écrit :
I'm trying to figure out the most painless way, given a set, to return the
set's values as an array.
Possibilities:
1) harmony wiki (
http://wiki.ecmascript.org/doku.php?id=harmony:iteratorss=iterator)
suggests the following, but it is a syntax error in traceur, continuum and
node --harmony
let arr = [e for e of mySet];
2)The ES6 standard supports the following production (i.e. expression, not
var, before 'for'):
*IterationStatement : for ( LeftHandSideExpression of
AssignmentExpression ) Statement*
(see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-13.6.4.2)
which suggests I should be able to do this:
let arr = [];
for (arr[arr.length-1] of mySet);
(I can do the equivalent with for-in) but that also errors in the above
three transpilers
3) So then I'm left with the pedestrian:
let arr = [];
for (e of mySet) {
arr.push(e);
}
4) I also wondered if Array.from(mySet) would do the trick but again
doesn't seem to pass muster with any of the above transpilers. (continuum
returns a zero length array and the other two don't know Array.from)
Wondering if I'm missing something better.
thanks
Angus
@angustweets
___
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
Set to Array conversions
I'm trying to figure out the most painless way, given a set, to return the
set's values as an array.
Possibilities:
1) harmony wiki (
http://wiki.ecmascript.org/doku.php?id=harmony:iteratorss=iterator)
suggests the following, but it is a syntax error in traceur, continuum and
node --harmony
let arr = [e for e of mySet];
2)The ES6 standard supports the following production (i.e. expression, not
var, before 'for'):
*IterationStatement : for ( LeftHandSideExpression of AssignmentExpression
) Statement*
(see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-13.6.4.2)
which suggests I should be able to do this:
let arr = [];
for (arr[arr.length-1] of mySet);
(I can do the equivalent with for-in) but that also errors in the above
three transpilers
3) So then I'm left with the pedestrian:
let arr = [];
for (e of mySet) {
arr.push(e);
}
4) I also wondered if Array.from(mySet) would do the trick but again
doesn't seem to pass muster with any of the above transpilers. (continuum
returns a zero length array and the other two don't know Array.from)
Wondering if I'm missing something better.
thanks
Angus
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin() reacher proposal
Lending my support to Object.mixin accepting a function as the argument—but
no surprise there I guess :)
Note: since functional mixins and constructors are syntactically identical
we can now get gorgeously expressive—and make type inheritance way simpler
(for the first time allowing multiple type inheritance)
//make a new thing and a new thang
var thing = new Thing;
var thang = new Thang;
//OR have Thung inherit from Thing and Thang
Object.mixin(Thung.prototype, Thing);
Object.mixin(Thung.prototype, Thang);
On Sun, Apr 14, 2013 at 12:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
right, I've simplified a lot and tested cross platform:
https://github.com/WebReflection/object-mixin#object-mixin
thoughts?
On Sun, Apr 14, 2013 at 10:07 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
OK, maybe just code was a non-sense ...
So, the idea behind is mark a function explicitly as mixin ... how ?
Any function that is passed and has an empty prototype (then is user
defined or native) could be considered invocable as mixin.
function addFunctionality() {
this.method = function () {
// now the outer context has a method
};
}
// mark the prototype as empty in ES5
delete addFunctionality.prototype.constructor;
function MyClass() {}
Object.mixin(MyClass.prototype, addFunctionality);
rather than only
Object.mixin(MyClass.prototype, {method: function () {}});
If the prototype has at least one own property in its prototype it will
be considered a constructor so that:
Object.mixin(MyClass.prototype, MySuperClass);
can easily be transformed implicitly into:
Object.mixin(MyClass.prototype, MySuperClass.prototype);
This case is, however, less important, the fact Object.mixin should be
able to accept a function and invoke it with target as context with
optional arguments would be really a **great idea**, IMHO
Thanks
On Sun, Apr 14, 2013 at 2:45 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also, in case you are guessing the typo .. reacher because it could
reach more (older) engines, doing a joke with richer got it? .. too
damn fun, I know!
On Sun, Apr 14, 2013 at 2:04 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
apologies
getOwnPropertyDescriptor(
source,
key
)
should have been
getOwnPropertyDescriptor(
enricher,
key
)
On Sun, Apr 14, 2013 at 1:58 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
what I've written here:
https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js
is a better proposal for the potential `Object.mixin()` in current ES6
specs.
It seems that Mixins Are Awesome and this can take most advantages
from being a function and not only an object:
http://webreflection.blogspot.ie/2013/04/flight-mixins-are-awesome.html
AFAIK, all interfaces described in W3C such EventTarget and others
could be also covered by this proposal ... so ... what do you think ?
/*jslint browser: true, forin: true, plusplus: true, indent: 4 */
(function(Object, mixin) {
use strict; // happy linter ^_^
/* droppable
* adhoc polyfill section for this purpose only
* never use these functions outside this closure ... like ...
ne*/var
/*
^ ... you see that? only reason I chose 4 spaces indentations here :D
also this comment ... pure quality, right ?!?! ... anyway ... */
// for IE 9 Desktop browsers
defineProperty = Object.defineProperty ||
function (o, k, d) {
o[k] = d.value;
},
// same as above
getOwnPropertyNames = Object.getOwnPropertyNames ||
function (o) {
var
// in case the guy does not inherit from
Object.prototype
has = Object.prototype.hasOwnProperty,
result = [],
key;
for (key in o) {
// in non ES5 compliant browsers
// there's no way to define properties
// as non enumerable unless these are
// there by default, like constructor is
// for functions.prototype
if (has.call(o, key)) {
result.push(key);
}
}
return result;
},
// again ... IE 8
getOwnPropertyDescriptor = Object.getOwnPropertyDescriptor ||
function (o, k) {
return {
enumerable: true,
writable: true,
configurable: true,
value: o[k]
};
};
// /droppable
// if already defined get out of here
// this should be
// if (mixin in Object) return;
// but for some reason I went for JSLint ...
if (Object[mixin]) {
return;
}
// same descriptor as other spec'd methods
defineProperty(
Object,
mixin,
Re: Object.mixin() reacher proposal
yeah that's better - I was having a senior moment - most constructor
functions will normally reside in the prototype of course
On Sun, Apr 14, 2013 at 1:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
My previous version was doing that in a probably too smart way so I've
simplified the proposal simply accepting, in that example
Object.mixin(Thung.prototype, Thing.proottype);
Object.mixin(Thung.prototype, Thang.proottype);
It does not look so black magic anymore but it's way less ambiguous than
the first proposal (I guess)
Thanks
On Sun, Apr 14, 2013 at 1:34 PM, Angus Croll anguscr...@gmail.com wrote:
Lending my support to Object.mixin accepting a function as the
argument—but no surprise there I guess :)
Note: since functional mixins and constructors are syntactically
identical we can now get gorgeously expressive—and make type inheritance
way simpler (for the first time allowing multiple type inheritance)
//make a new thing and a new thang
var thing = new Thing;
var thang = new Thang;
//OR have Thung inherit from Thing and Thang
Object.mixin(Thung.prototype, Thing);
Object.mixin(Thung.prototype, Thang);
On Sun, Apr 14, 2013 at 12:59 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
right, I've simplified a lot and tested cross platform:
https://github.com/WebReflection/object-mixin#object-mixin
thoughts?
On Sun, Apr 14, 2013 at 10:07 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
OK, maybe just code was a non-sense ...
So, the idea behind is mark a function explicitly as mixin ... how ?
Any function that is passed and has an empty prototype (then is user
defined or native) could be considered invocable as mixin.
function addFunctionality() {
this.method = function () {
// now the outer context has a method
};
}
// mark the prototype as empty in ES5
delete addFunctionality.prototype.constructor;
function MyClass() {}
Object.mixin(MyClass.prototype, addFunctionality);
rather than only
Object.mixin(MyClass.prototype, {method: function () {}});
If the prototype has at least one own property in its prototype it will
be considered a constructor so that:
Object.mixin(MyClass.prototype, MySuperClass);
can easily be transformed implicitly into:
Object.mixin(MyClass.prototype, MySuperClass.prototype);
This case is, however, less important, the fact Object.mixin should be
able to accept a function and invoke it with target as context with
optional arguments would be really a **great idea**, IMHO
Thanks
On Sun, Apr 14, 2013 at 2:45 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
also, in case you are guessing the typo .. reacher because it could
reach more (older) engines, doing a joke with richer got it? .. too
damn fun, I know!
On Sun, Apr 14, 2013 at 2:04 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
apologies
getOwnPropertyDescriptor(
source,
key
)
should have been
getOwnPropertyDescriptor(
enricher,
key
)
On Sun, Apr 14, 2013 at 1:58 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
what I've written here:
https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js
is a better proposal for the potential `Object.mixin()` in current
ES6 specs.
It seems that Mixins Are Awesome and this can take most advantages
from being a function and not only an object:
http://webreflection.blogspot.ie/2013/04/flight-mixins-are-awesome.html
AFAIK, all interfaces described in W3C such EventTarget and others
could be also covered by this proposal ... so ... what do you think ?
/*jslint browser: true, forin: true, plusplus: true, indent: 4 */
(function(Object, mixin) {
use strict; // happy linter ^_^
/* droppable
* adhoc polyfill section for this purpose only
* never use these functions outside this closure ... like ...
ne*/var
/*
^ ... you see that? only reason I chose 4 spaces indentations here :D
also this comment ... pure quality, right ?!?! ... anyway ...
*/
// for IE 9 Desktop browsers
defineProperty = Object.defineProperty ||
function (o, k, d) {
o[k] = d.value;
},
// same as above
getOwnPropertyNames = Object.getOwnPropertyNames ||
function (o) {
var
// in case the guy does not inherit from
Object.prototype
has = Object.prototype.hasOwnProperty,
result = [],
key;
for (key in o) {
// in non ES5 compliant browsers
// there's no way to define properties
// as non enumerable unless these are
// there by default, like constructor is
// for functions.prototype
if (has.call(o, key)) {
result.push(key);
}
}
return
Re: Jan 30 TC39 Meeting Notes
No I more-or-less agree with your spiel. I'm unclear why the group considered let/const is an issue for sloppy mode. On Sun, Mar 10, 2013 at 9:57 PM, Rick Waldron waldron.r...@gmail.comwrote: On Sun, Mar 10, 2013 at 7:50 PM, Angus Croll anguscr...@gmail.com wrote: Thanks for this Rick. From the minutes, I'm not getting the rationale for banishing let/const from sloppy mode. Are you specifically asking about my big spiel? I stated that disallowing any new syntax (not just let/const) in non-strict mode would result in stunted adoption and too many rules confusion. Despite my belief that strict mode is the right mode, I also asserted that it's simply unrealistic to think that new syntax is a big enough carrot. Important to note that I'm not speaking for anyone that reads or participates on this list. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Jan 30 TC39 Meeting Notes
got it, thanks On Mon, Mar 11, 2013 at 2:16 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I think this thread is the most recent discussion of the issue: http://esdiscuss.org/topic/1944 -- *From:* es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Angus Croll [anguscr...@gmail.com] *Sent:* Monday, March 11, 2013 17:08 *To:* Rick Waldron *Cc:* TC39; es-discuss *Subject:* Re: Jan 30 TC39 Meeting Notes No I more-or-less agree with your spiel. I'm unclear why the group considered let/const is an issue for sloppy mode. On Sun, Mar 10, 2013 at 9:57 PM, Rick Waldron waldron.r...@gmail.comwrote: On Sun, Mar 10, 2013 at 7:50 PM, Angus Croll anguscr...@gmail.comwrote: Thanks for this Rick. From the minutes, I'm not getting the rationale for banishing let/const from sloppy mode. Are you specifically asking about my big spiel? I stated that disallowing any new syntax (not just let/const) in non-strict mode would result in stunted adoption and too many rules confusion. Despite my belief that strict mode is the right mode, I also asserted that it's simply unrealistic to think that new syntax is a big enough carrot. Important to note that I'm not speaking for anyone that reads or participates on this list. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Questions on Proper Tail Calls
1. Will proper tail calls only happen in strict mode, and if not are we ok with losing backwards compatibility re. [function].caller and [ callingFunction].arguments? 2. Will tail call behavior apply regardless of the tail call syntax? (fn(), fn.call, fn.apply)? 3. Will tail call behavior apply even when the tail call is not recursive? 4. If function fn has a function call in the tail position and is then bound (fn2 = fn.bind(x)), will fn2 also support proper tail calls? (I think this is only relevant if (3) is true) thanks ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on Proper Tail Calls
Thanks Allen, those are the answers I wanted to hear :) Seems like ES 6 proper tail calls will be a good for CPS too. On Sat, Mar 9, 2013 at 5:22 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Mar 9, 2013, at 3:00 PM, Angus Croll wrote: 1. Will proper tail calls only happen in strict mode, and if not are we ok with losing backwards compatibility re. [function].caller and [ callingFunction].arguments? Apparently yes, there is a note in the draft that we reached that conclusion at a TC39 meeting 2. Will tail call behavior apply regardless of the tail call syntax? (fn(), fn.call, fn.apply)? yes, assuming that the actual call to fn is in a tail position within the call or apply function implementations. I'll review to spec. to make sure. 3. Will tail call behavior apply even when the tail call is not recursive? yes 4. If function fn has a function call in the tail position and is then bound (fn2 = fn.bind(x)), will fn2 also support proper tail calls? (I think this is only relevant if (3) is true) yes, it is only based upon the syntactic structure of the function making the call, not it's bindings thanks ___ 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: arrows and a proposed softCall
Yes the thread needs wrapping up. Maybe I can attempt summarize the dilemma - with a question: Is call/apply just a remedy for non-lexical this assignment? Or is it a powerful feature in it own right. I'm with the second camp, but I think I'm in the minority in this list On Tue, Jun 5, 2012 at 10:23 AM, Brendan Eich bren...@mozilla.com wrote: Russell Leggett wrote: On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich bren...@mozilla.commailto: bren...@mozilla.com wrote: What I perceive from the JSFixed effort, and from Angus who is good enough to post here: people have a particular concern that fat-arrow is too sweet and it will lure the children into the witch's house: passing fat arrows to dynamic-this APIs. We have data suggesting that fat arrows address the dominant use-case, thanks to Kevin Smith and others. So fat arrows are in ES6, well and good. I think the particular concern about = being an attractive nuisance for some APIs such as Angus's mixin combinators, which rely on .call overriding |this|, can be addressed by adding - too. Angus agrees, but - is not on the boards for ES6 (yet). We could try to revive -, but first, we should face the attractive nuisance argument squarely, instead of dancing around it with isBound abuses that try to catch fat arrow going into the witch's house. I think that with -, a similar problem will still crop up - specifically that = will be the more common use, and then in the rare case that - is needed, people may still use =. I agree. The problem we'll then see is anxiety over which arrow? -- the Paradox of Choice (Schwartz). Do we still need isBound to catch that error as well? Even with the choice of - or =, the person writing the code has to know which one to use and why. That means they have to understand the whole dynamic |this| problem. Agreed, so (while we are spiraling, no worries) this helps. We cannot remove the dynamic vs. bound |this| choice from JS. But we can avoid adding choice when shortening, based on use-case frequency analysis. This, we have done (many thanks to Kevin Smith again), and it is why = got into ES6. I think that the dynamic |this| behavior of jQuery is not something that should be encouraged. I understand it is probably mostly that way because of the dom event api, JQuery goes further, I think simply due to mimesis. The DOM binds |this| to the event target but in the context of the old DOM level 0, where the only way to attach an event handler was as a method of the target, this was not wrong. JQuery goes much, much further down the path to crazy |this| dynamic binding. but that doesn't change the fact that it really has a bad smell to it. On this everyone agrees. No disrespect to JQuery, but it is important to know what *not* to imitate. We know now, so we shouldn't be using JQuery as a rationale for dynamic-this short forms or isBound as a general tool. CoffeeScript has -, but if you look at the examples, none of them actually make use of dynamic |this| except for methods, and we're adding a nice method syntax, so it isn't really needed. Method syntax, and = should cover the majority of cases and lead people down the right path. This is the current ES6 state and rationale, indeed. I know this is going around in a circle, but my point is that adding - doesn't fix the problem, which is devs not knowing when to use = and when to use function. It's a good point. I hope we can wrap this thread up. It has been helpful to disclose or emphasize the situation: 1. soft-bind breaks abstractions and won't fly with implementors. 2. isBound needs more discussion but it too breaks abstractions and it must be defined (Mark's definition) to work for all this-insensitive functions. 3. = covers the dominant use-case for functions not using |this| and functions capturing lexical |this| via .bind or var self=this. 4. Adding - doesn't avoid confusion over whether to use = or function, it only adds a shorthand -- good for those who want this -- and at the same time (the paradox of choice) creates anxiety over which arrow do I use?. We could add isBound. We could add - too. Right now ES6 has = only, based on a weighting of the costs and benefits in 1-4. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
I actually agree. I included non-this methods only because reading through
this thread I got a feeling that there was some consensus that they be
treated differently. More than happy to not do that.
On Mon, Jun 4, 2012 at 8:16 AM, Andreas Rossberg rossb...@google.comwrote:
On 3 June 2012 20:13, Angus Croll anguscr...@gmail.com wrote:
Not suggesting that arrow functions be special cased or that they ignore
|thisArg|. I'm suggesting for all relevant cases (=, bind and no
|this|) we
only throw an error on call/apply if the |thisArg| is non null.
That would not only be a breaking change, as Brendan pointed out. More
importantly, it would also not be something you truly want. Consider
this piece of code:
function C(x) { this.x = x }
C.prototype.f = function() { return this.x }
C.prototype.g = function() { return this.f() * 2 }
C.prototype.h = function() { return 41 }
let o = new C(21)
foo(o, [o.f, o.g, o.h])
where
function foo(o, funs) {
// ...
for (let f of values(funs)) {
result += f.call(o)
}
}
According to your suggestion, foo would throw. But there is no actual
reason why foo should care that h is a constant method. That's an
implementation detail. Why should the caller have to jump through
hoops to account for implementation details of the callee?
I think there is a misconception here is that this-oblivious
methods/functions are something _different_ from normal
methods/functions. They aren't. They are just a _special case_ of
normal methods/functions. Just like functions that ignore any other
parameter. Consequently, you don't usually want to treat them
differently. I claim that code that tries has a 98% likelihood of
being broken -- or at least of smelling rather bad.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich bren...@mozilla.com wrote:
You mean you still propose that (= 42).call({}) should throw, but
(function () { return 42; }).call({}) should not?
Sorry, this isn't a principled response. There should be no difference in
result between those two cases.
I disagree. You yourself said so are you looking for an isBound predicate
just to throw an error? I'm not saying that is a non-goal. The principal
is let the user know they are trying to set |this| in a hard bound
function. The level of introspection required to go the extra mile and look
for |this| usage seems neither desirable or useful. If my function doen't
reference |this| then I don't care if |this| is modifiable.
However I thought we had some agreement that - was a valid goal. In which
case this error throwing stuff is less important (to me at least)
Apart from principles, it seems to me you think arrows will be such sweet
sugar that people will make mistakes using this-sensitive API contracts,
where long-but-this-insensitve-**functions would not be so misused.
To demonstrate this we need to see some evidence. It's not enough to
worry, or to hypothesize unfixed code shipped and failing at scale due to
failure to test arrow function misuse on the part of developers.
I'm the first to admit I have no hard evidence, only heresay
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On Jun 2, 2012, at 23:14, Brendan Eich bren...@mozilla.org wrote: Angus Croll wrote: To my mind (2) is the actual problem. To quote Yehuda the proposed semantics interfere with more intentional uses of `call` and `apply`. Users of call and apply who need to override |this| have as their contract that any funarg they take has dynamic |this|. Yes of course, can't argue with that logic, or your earlier explanation of why modern engines can't be expected to have call/apply modify a hard binding. But that's exactly why we should be conservative about locking users into hard bindings when their intentions are not clear (clear: 'bind' or no |this| value, unclear: arrow functions). As someone who views call/apply as cornerstones of the language and who's libraries depend on it, an unintended hard binding is a needlessly broken utility. But I repeat myself. So are you looking for an isBound predicate just to throw an error? I'm not saying that is a non-goal, I'm just asking to find out if there's some other, non-throwing recourse your code could use. I'm not looking for an isBpund predicate - not sure the dividends would be worth the effort. If the hard-binding is non-negotiable then it would be more useful (and instructive for the user) for call/apply to tell me why it won't change my context - I'd rather it throw an error* than have our utils silently fail because the user was unaware of the semantics of =. *If the intention is to use call/apply purely as an argument passer this can be indicated by a null context argument which would suppress the error /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On Jun 2, 2012, at 23:14, Brendan Eich bren...@mozilla.org wrote: So are you looking for an isBound predicate just to throw an error? Sorry misread your question. Yes. For reasons stated. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
But that's exactly why we should be conservative about locking users into
hard bindings when their intentions are not clear (clear: 'bind' or no
|this| value, unclear: arrow functions). As someone who views call/apply as
cornerstones of the language and who's libraries depend on it, an
unintended hard binding is a needlessly broken utility. But I repeat myself.
Are you arguing for - instead of =, or in addition to =?
At this point I'd settle for anything that allowed both abbreviated syntax
and late binding via call/apply. That could be any of:
1) Arrow function that shortens syntax but leaves semantics alone
2) Arrow function with soft lexical binding
3) Thin arrow as no-semantic alternative to fat arrow (coffee script style)
Looks like (3) has the most chance of gaining acceptance - that would work
for me.
There's nothing particularly unclear about a function that doesn't use
|this| or else binds |this|, vs. a function that uses its dynamic |this|.
Clarity depends on many things including how well documented or commented
the code -- especially that contract that we just agreed exists -- might be.
So why are arrow functions unclear? Asserting that they are doesn't
prove the point. It seems to me you're assuming too many developers won't
learn that = means lexical |this|, and that they'll continue not to learn.
Its impossible for me to prove they are unclear just as its impossible for
you to prove they are clear. I can only:
1) point to the syntax and suggest 'bind' says exactly what it does while
'=' says nothing about what it does
2) point to unscientific and noisy issue comments at jsfixed and note that
at least some experienced JS devs share my concerns re. lack of clarity
https://github.com/JSFixed/JSFixed/issues/42
https://github.com/JSFixed/JSFixed/issues/20
Also note that here, several fine developers got into a mess with figuring
out the impact on 'this' in fat arrows
https://github.com/JSFixed/JSFixed/issues/30
But I readily admit that I won't know how valid my concerns are until the
syntax starts being used in anger.
*If the intention is to use call/apply purely as an argument passer this
can be indicated by a null context argument which would suppress the error
This is an incompatible change if done for any function that ignores the
|thisArg|:
js function f() { var self = this; return function () { return self.foo;
} }
js var g = f()
js var o = {m: f, foo: o.foo}
js var h = o.m();
js var foo = global foo
js g.apply(null)
global foo
js h.apply(null)
o.foo
js g.apply({foo: new foo})
global foo
js h.apply({foo: new foo})
o.foo
Same for ES5 bound functions:
js function unb() { return this.foo; }
js var b = unb.bind({foo: b.foo})
js b.apply(null)
b.foo
js b.apply({foo: new foo})
b.foo
Why should only arrow functions, among all functions that ignore
|thisArg|, throw when applied with a non-null |thisArg|?
Not suggesting that arrow functions be special cased or that they ignore
|thisArg|. I'm suggesting for all relevant cases (=, bind and no |this|)
we only throw an error on call/apply if the |thisArg| is non null.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
related: are explicitly bound functions going to get a 'target' reference
to the unbound function in ES6? I've manually set this property many times
(mainly for debugging)
On Thu, May 31, 2012 at 9:05 PM, Mark S. Miller erig...@google.com wrote:
On Thu, May 31, 2012 at 7:44 PM, David Herman dher...@mozilla.com wrote:
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
if (isBoundOrWhateverWeCallIt(f)) {
//... do something
} else {
//... do something else
}
If the predicate means what I think it should mean, I can offer some
examples of when I would do this.
Could you? I haven't yet understood what you want your predicate to mean
or what you want it for.
Take a look at slides 45 and 46 of
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5
http://qconsf.com/dl/qcon-sanfran-2011/slides/MarkS.Miller_RemainingHazardsAndMitigatingPatternsOfSecureMashupsInEcmaScript5.pdf
Rewind first to remind yourself of enough context to get the point.
Rather than teach defensive programmers to write
(1,subscribers[+i])(publication);, I think it is both more robust
and more teachable to teach them to do input validation where they
accept a function that they expect to not be this-sensitive.
subscribe: function(subscriber) {
if (!isBoundThisOrWhateverWeCallIt(subscriber)) {
throw Error(only non-this-sensitive functions (such as
bound functions) may be subscribers);
}
subscribers.push(subscriber);
}
Amusingly, the example becomes exactly the inverse of Allen's,
leveraging soundness rather than fighting incompleteness.
We could instead make the subscribe method defensive by writing
subscribe: function(subscriber) {
subscribers.push(subscriber.bind(undefined));
}
This would be as safe; it would successfully prevent the same attacks.
When the attacks are due to malice, this would be as good -- better
since it is simpler. But most attacks are actually accidents, not
malice. This simpler alternative fails to give an early diagnostic to
accidental attackers -- which is directly analogous to the test's
purpose in Allen's code. The (1,subscribers[+i]) technique shown on
the slide has the same lack-of-early feedback problem.
With the isBoundThisOrWhateverWeCallIt test as previously proposed,
callers of subscribe can only successfully call it with either a fat
arrow function or a bound function, which is often an unnecessary
burden on these callers. With the test I propose, callers can also
successfully call it with any function that neither mentions this nor
contains a direct eval operator. The remaining false negatives of my
test would cause only the minor annoyance of unnecessarily rejecting
safe cases like
subscribe(function() { if (false) { doSomethingWith(this); } });
--
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: arrows and a proposed softCall
On Wed, May 30, 2012 at 2:01 PM, Rick Waldron waldron.r...@gmail.comwrote: a means of detecting bound functions would essentially mitigate any perceived pain points of fat-arrow-functions. If we can get consensus on something like this, it would allay community concerns about the fat arrow. 1) It would tell us when we can't change the context via call/apply. 2) It would still prevent us from changing the context via call/apply To my mind (2) is the actual problem. To quote Yehuda the proposed semantics interfere with more intentional uses of `call` and `apply`. ___ 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: TC39 bashing
You have some valid points Axel. Maybe the biggest problem is one of communication - JSFixed has received a lot of attention and many followers in just a few days - which suggests developers want more access to the process by which the language is developed. To that end I hope we are providing a service. Incidentally the advisory forum with voting which you suggest is exactly what JSFixed is now providing. Apologies if the JSFixed project has spawned or even encouraged anti-TC39 sentiment. Anton, Kit and I committed to keeping things civil and respectful on our side. In any case its my hope, as developer advocates we can offer useful input to the TC39 process. Angus On Wed, May 9, 2012 at 4:46 PM, Axel Rauschmayer a...@rauschma.de wrote: I’m seeing quite a bit of anti-TC39 sentiment out there and I don’t think it’s fair. Some examples (paraphrasing): - “TC39 doesn’t care about web developers and/or doesn’t understand web development.” - “TC39 ignores what the people want and designs ‘by committee’.” - “TC39 is moving too slowly, does too little.” The following are counter-points to those opinions: - If you want to do good design, it is impossible to please everybody. Design by popular vote is worse than design by committee. That’s why we have representative democracies. - Evolving the language while remaining backward compatible is a hard problem. I like what TC39 has done so far. The main goal must be to have as clean a language as possible in the future. Doing so while being backward compatible means that the transition can be a little messy (several similar constructs existing in parallel etc.), but that is unavoidable. One doesn’t need to understand all the gory details as long is things are simple *in practice*. - TC39 has a lot of responsibility and must keep many parties happy. The payoff, however, is huge: I’m not aware of any other programming language that is as open and has as many different, yet highly compatible, implementations. Hence, moving at a deliberate pace is a good thing. Compare with how much progress Java has made over the years (in an environment that is much simpler than JavaScript’s). In that light ES.next’s progress looks quite good. - I find es-discuss quite open and appreciate it as a resource. I see TC39 members expend a lot of energy and patience in answering as many questions as possible. Every now and then a question won’t be answered. But that is understandable, as es-discuss is not a support hotline that has to cover 100% of the questions. What could be improved: - Make it easier to search the mailing list archives. Might be a minor thing, but it would really help. I wonder how Brendan always finds those old threads that are relevant to a particular topic. - Possibly add an FAQ. This could be as simple as collecting all emails that have long-term explanatory value. - I like the idea of having a forum what some people can suggest ideas and everyone can vote on them. One would need both up-votes and down-votes, as there is bound to be a lot of troll material. Such a forum can only ever have an advisory role. But it gives developers the opportunity to vent their feelings and it gives TC39 popular feedback (including ideas that might not have come up before). By bundling requests, traffic is reduced. - Some complaints are about evolving the standard library (including collection types). I’ve seen Brendan hint at a strategy for doing so, but I’d love to read more about it. Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.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: Bound instance-function vending (was RE: Arrow binding)
On Apr 28, 2012, at 22:24, Axel Rauschmayer a...@rauschma.de wrote:
The following two rules should be everything one has to know regarding
callable entities, in ES.next:
1. Method: `this` is an implicit parameter = use a method definition.
2. Non-method function: `this` is not an implicit parameter = use an arrow
function.
In this light, I’d rewrite Kevin’s code slightly, because, conceptually,
`localStorage ` is a non-method function:
const localStorage = (obj) = {
Object.extend(obj, {
If I understand correctly, this approach negates the need for a mixin function
entirely - localStorage could just be an old style mixin hash.
But either way this tosses out the benefits I get from functional mixins. By
invoking the mixin instead of copying it I can a) customize it's behavior by
passing it arguments b) have the mixin add advice (before, after, around) to
functions of the target object.
I think Angus’ most important point is this:
Yes, people get confused by this binding; even though it is not hard to
learn the rules, and I know them very well, I still trip over them
sometimes. But unless we are going to introduce a hella strict mode that
reverts all previous rules of |this| binding, yet another rule will just add
to the morass.
It would be my hope that we can replace all previous rules with the two rules
above. `apply` will mostly be replaced by the spread operator, `call` will
mostly be replaced by calling a value. Some code such as `forEach`
implementations that previously needed to use `call` to simulate lexical
scoping don’t need a `thisValue` parameter for array functions.
I admire the vision but in reality the boundary between ES5 and ES6 will be
messy and drawn out - there will be no clear cut switching point. Legacy code
must live alongside the new vision. Without a new strict mode which banishes
much of the old spec (and kills my functional mixins) I'm finding it hard not
to picture chaos. (and how do you shim = anyway?)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Bound instance-function vending (was RE: Arrow binding)
On Apr 29, 2012, at 1:28, Brendan Eich bren...@mozilla.org wrote: Axel Rauschmayer wrote: I am not saying that the transition from the old rules to the new rules will be entirely painless, but if the new rules are simple, that pain is worth it, IMHO. There are no new rules. Some functions ignore |this| or bind it rather than using it. These differences in kind do not change due to arrows. Is there lexical |this| binding in ES5? Angus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bound instance-function vending (was RE: Arrow binding)
Then I guess we need another survey. What does the JS arrow function proposal mean to you? a) An abbreviated function syntax b) A hard bound lexical |this| binding c) Nothing I'd gladly be proved wrong but my guess is most JS developers who don't answer (c) will answer (a). (I see plenty of supporting evidence on Twitter). Thin arrow would be an excellent decoy for those who expect (or want) just (a). This is also in response to Kevin's suggestion that arrow syntax is barely more concise than regular function syntax. I don't think that's the perception in the wider dev community, neither is it mine (in the best case we save four ways - no function keyword, no braces, no argument parens, no return stmt). Personally I expect I can get by using function keyword where using = will break my idioms - but its a bit much to expect everyone to understand and react to these subtleties. I guess I'm trying to anticipate future cowpaths and pave them before they make too much mess. On Sun, Apr 29, 2012 at 11:37 AM, Brendan Eich bren...@mozilla.org wrote: Brendan Eich wrote: But the lexical part doesn't enter into the contract of the API taking the function argument. It's between the API caller and the function argument's implementation -- when the latter is a closure in the former, lexical |this| often wins. What does enter into the contract of the API taking the function argument is whether |this| is dynamically bound and passed with the expectation that the funarg not use some other |this|. But even then, the funarg is free to ignore |this|. Between lexical-this and no-this, Kevin's analysis shows 80-90% (high end helped by method definition shorthand) coverage. Thinking about arrows as a new thing to teach is fine, but we should not teach myths. |this| binding in JS today requires careful thought in all the usual scenarios: constructor, method, callback, global or local function. You can see why some advocate no-this uber alles! But lexical-this is (if memory serves) around 40-50% gross of the 80-90% Kevin studied. That's big and we know people get that wrong. If there's a strong use-case for - as function shorthand, we should consider adding - too. But the use-cases don't look strong enough yet, at least not to me (and I'm sympathetic!) to go back to TC39 asking for - on top of =. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bound instance-function vending (was RE: Arrow binding)
I'm sorry that I could not reply to the multiple replies I got last weekend. Simply can't get the time - plus I have a phobia of fan-out replies (an issue with mail-based discussion groups?) In any case here's a potted reply that addresses at least some of the points: 1) Kevin et al suggested YAGN call/apply on (non-method) functions. Here's a pretty neat example where call/apply is a perfect fit for standalone functions - and would break if replaced with fat arrows. https://gist.github.com/2520731 It's a simplified version of a a localStorage function (itself a mixin BTW) which defines standard encoding methods and then mixes in whatever storage technique is available to the browser. (An added bonus of having functions here, aside from privacy, is that we can employ hoisting to move the implementation nitty-gritty to the bottom, so as not to obscure the core process) 2) Brendan et al pointed out that we already have hard |this| binding in the form of Function::bind. Yes, but bind is so blatantly explicit in its intention, the probability of surprise is almost certainly less than with arrow functions, whose hard lexical binding will surely come as a surprising side effect to many. 3) Several people suggested that there is a strong desire for a more intuitive form of |this| binding. Yes, people get confused by this binding; even though it is not hard to learn the rules, and I know them very well, I still trip over them sometimes. But unless we are going to introduce a hella strict mode that reverts all previous rules of |this| binding, yet another rule will just add to the morass. Most of the yay, fat arrow comments I've seen from the dev community are celebrating its brevity, I expect many of the authors have zero knowledge of the lexical binding implications (why would they, unless they came from CoffeeScript?). Now matter how much we justify fat arrow behavior as part of a long term vision, to many it is going to be a hidden, and unwanted side effect. At least introduce thin arrow at the same time, as a carrot to lure who just want (and just expect) an abbreviated function syntax. On Mon, Apr 23, 2012 at 3:01 PM, Brendan Eich bren...@mozilla.org wrote: Brendan Eich wrote: No, in any such prototype-getter-makes-bound-**function scenario, we would need memoization, so that o.m === o.m (Edit: I see you mention this below.) The real problem is better captured by showing the prototype p and two instances, o and q: p.m === p.m should be true. So should o.m === o.m and q.m === q.m but what about o.m === p.m and o.m === q.m JS requires distinct bound function identity from the unbound p.m identity, so false and false. If we managed to extend JS with a classy declarative syntax that enabled vtables, while keeping functions first class (at the price of prototype-chain mutation: assignment to override, or shadow; also of course delete), then we might well want true and true. But there would be no way in JS itself to implement such magic in terms of properties (data or accessor, doesn't matter) with function values. This is why I continue to think that we won't see what Alex predicted: prototype getter method vending. We haven't see it much in the wild yet either. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A few arrow function specification issues
4) Should it be a dynamic error to try to use apply/call to set the this
binding of an arrow function.
Cons
To much existing code speculatively binding the this value when invoking
a function.
I propose that call/apply simply ignore the this value when invoked on an
arrow function.
What is the pro of ignoring explicit |this| binding instructions in
call/apply on arrow functions?
What is the con of continuing to allow legacy code to speculatively bind
the |this| value when invoking any function?
Why is it so important that fat arrows do a hard |this| binding?
On Fri, Apr 20, 2012 at 4:22 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Here are a few design alternates that have come up as I work the
specification draft for arrow functions
1) Always strict? Should all arrow functions be considered strict
functions?
Pros
It's a new syntactic form, so it is it easy to make it be an implicit
opt-in to strict mode.
We generally want to encourage use of strict mode.
If not, there would no way to to make an expression-bodied arrow function
a strict function (other than by nesting it in strict code)
Always strict eliminates the need for some of the arrow special case
alternatives discussed below
Cons
We shouldn't be trying to force use of strict mode.
Programmers who don't know about strict mode may get confused by the
application of strict mode semantics to arrow functions
It would create a refactoring hazard for non-strict code.
2) Redeclaring eval in non-strict arrow functions
Should strict mode eval declaration/assignment restrictions be be imposed
upon non-strict arrow functions?
I propose disallow binding eval or assigning to it all arrow functions
3) Declaring arguments as a formal parameter, or local binding in a
non-strict arrow function
The wiki proposal says arguments can't be used as an expression primary
but doesn't say anything about declarations
I propose binding or assigning or referencing arguments within a arrow
function.
4) Should it be a dynamic error to try to use apply/call to set the this
binding of an arrow function.
Cons
To much existing code speculatively binding the this value when invoking a
function.
I propose that call/apply simply ignore the this value when invoked on an
arrow function.
5) Should arrow functions define the [[HasInstance]] internal method.
In other words should should:
obj instanceof () = {}
do?
If it doesn't have [[HasInstance]] then instanceof would throw a type
error. Alternatively, it could have a [[HasInstance]] that always returns
false.
We have already decided that arrow functions don't have a [[Construct]]
internal method nor a prototype property.
I propose that arrow functions do not have a [[HasInstance]] internal
method.
6) Do arrow functions need to have per instance caller and arguments
poison pill properties?
I propose no, because they are a new feature. But we can include a NOTE
warning against providing their non-standard legacy implementation.
7)All of the above questions also apply to functions defined using concise
method syntax in object literals or classes. Should the same answers apply
to them?
___
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: A few arrow function specification issues
a function shouldn’t work radically (and silently!) different depending
on how it is invoked
every current JS function behaves exactly this way :-)
I'm painfully aware that I sound like a broken record on this, but
introducing a hard-bound function option while continuing to suport
dynamic-bound functions everywhere else is not going to simplify anything.
Another function should not need to know how its function arguments were
created in order to work properly - thats a terrible anti-functional
anti-pattern!
Imagine
function(fn) {
//
if (fn.prototype) {
fn.apply(x);
} else {
throw Error(I can't call your function in my context);
}
}
On Sat, Apr 21, 2012 at 1:28 PM, Axel Rauschmayer a...@rauschma.de wrote:
I am in agreement with Angus on this one.
If there is no skinny arrow, hard |this| binding should not be part of the
spec. Fat arrow functions should default to lexical |this|, but if there is
no skinny arrow, it should not be a hard binding and call/apply should be
allowed, as well as bind,
IMHO, the spec got it exactly right. We have a chance to really simplify
things and introduce a clear distinction:
- Methods – dynamic `this`: Use a concise method definition inside an
object literal (or, hopefully, inside a class declaration).
- Non-method functions – lexical `this`: Use an arrow function.
Anything else is rare (see Kevin Smith’s JS code survey) and non-methods
with dynamic this are usually an anti-pattern. If you really need it, there
are always old-school functions.
As for switching between dynamic `this` and lexical `this` depending on
whether a function is called as a method or as a function. At first glance,
it sounds like a good idea, like the best of both worlds. However, I’m with
Domenic Denicola: it’s too brittle – a function shouldn’t work radically
(and silently!) different depending on how it is invoked. Switching to this
= undefined is bearable for old-school non-method functions, but switching
to lexical this will lead to many hard-to-debug errors.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic this
I like dynamic this.
I favor hard-bound lexical |this| for standalone function calls only. Thats
where the problems are right now
The (this, ...) syntax seems unnecessarily gnarly - better to just default
to using base ref as |this| in a method call - since by now this is
expected behavior
On Mon, Apr 9, 2012 at 10:46 AM, Herby Vojčík he...@mailbox.sk wrote:
Hello,
this is more a conceptual question post. But first some proposals that
circulated in the list:
1. Dynamic-this enabled fat arrow functions.
(this, ...) = expr
(this, ...) = { body }
2. ABC (apply/bind/call) shortcuts.
thisobj::identifier(...args) // apply
thisobj::identifier // bind
thisobj::identifier(arg, arg, ...) // call
Now, I like them both. I like this dynamic this being in the language and
things that it allows (ad-hoc methods). Sure it can be used wrong ways, as
everything.
The question is: is dynamic this liked (in the sense, is it the feature
which we see as valuable and as one we want proudly have in the language)
or is there rather the footgun/no-one-uses-it-right movement for
diminishing its role to strange relic?
I saw the mixed opinions.
Herby
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow function syntax simplified
On Fri, Mar 30, 2012 at 4:46 AM, Felix Böhm esdisc...@feedic.com wrote: How about a loose-bound |this|, so that the function falls back to the bound |this| instead of the global scope when no other options are available (or `null` or `undefined` are passed to `.apply/.bind/.call`)? I strongly support this proposal. Any legacy utility (3rd party or otherwise) that assumes its function arguments are dynamically bound (a reasonable assumption as of ES 5.1) will be in trouble when passed hard-bound fat arrow functions. Here's a gist illustrating a simplified version of a functional mixin process and how it would break under the current fat arrow proposal. https://gist.github.com/2266911 Yes we could use the long-form function instead, but it seems unnecessarily restrictive (not to mention confusing) that the much anticipated short-form syntax should be out-of-bounds whenever there is a remote possibility that the function may at some time need invoking with a different |this| value (and how can we even anticipate such a requirement? - especially if we are writing 3rd party libraries) And yes there is an ES 5 precedent - Function::bind also makes a hard binding, but with bind there are no surprises, it is intentional and explicit - fat arrow lexical binding OTOH will probably be an unexpected side effect for those developers whose primary goal is to save key strokes. Under Felix's proposal I'm assuming a soft-lexical binding would be overridable by call and apply (provided a valid context object is passed) or by the base reference of a method invocation. In other words if a |this| value is provided, use it, otherwise default to the lexical scope instead of the global scope. I'm betting that covers most of the current |this| headaches we are trying to solve while keeping short-form syntax in play for those of us who value/rely on dynamic binding. Angus ___ 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: arrow function syntax simplified
On Apr 8, 2012, at 4:00, Herby Vojčík he...@mailbox.sk wrote: No special cases for null or undefined, please. Fine. Then we should just default to lexical binding for standalone function calls - I'll stick my neck out and assert that it's the only area that needs fixing with respect to |this| binding Angus Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow function syntax simplified
I don't see anything that is broken by arrow functions. You are
attempting to use arrows for defining methods which is incorrect.
Sorry, I obfuscated unnecessarily by making the inner functions into arrows
too.
But the important one is the withCircleUtilsFat function which is not a
method
This would have been clearer
var withCircleUtilsFat = () = {
this.area = function() {return this.radius * this.radius * Math.PI};
this.diameter = function() {return this.radius + this.radius};
}
This would be correct:
function withCircleUtils() {
this.{
area() { return this.radius * this.raduis * Math.PI; },
diameter() { return this.radius + this.radius; }
};
}
Do you see a problem with this construction?
To reiterate: I am forced to use a long-form for withCircleUtils because we
attached special meaning to the short-form. I think the criteria as to when
to use short vs long-form will be unclear to many users and I can already
see a future Good Parts equivalent suggesting avoid arrows because the
rules of when to use them are unnecessarily complex. Switching to soft
lexical binding would remove these usage constraints. Indeed they would
also allow arrow functions to define methods without resorting to the
unwieldy initial 'this' argument proposal.
Bottom line: is the primary goal of arrow functions brevity or hard-lexical
binding? If its the former (and even if it isn't a lot of dvelopers will
percieve it as such) then we should be careful not to add usage caveats.
Angus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow function syntax simplified
Ha! nice catch :-)
My concern is with developers not knowing about the side effects of = and
therefore when to use it.
On Sun, Apr 8, 2012 at 4:09 PM, Kevin Smith khs4...@gmail.com wrote:
Which form has more brevity, then?
// This?
var withCircleUtilsFat = () = { ... };
// Or this?
function withCircleUtilsFat() { ... };
In any case, between object literal methods and arrow functions, I think
you'll find that the vast majority of your function expressions will get a
more concise syntax.
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Questions re. final fat arrow syntax
Apologies if this is not yet nailed down. I'm looking for the following
details re. the arrow function grammar which I was unable to determine from
the strawman proposal:
1. Will the syntax support more than an expression in the function body?
The proposal appeared to be veering towards expression only syntax -
although this could be mitigated by the ES 6 proposed do {} syntax.
2. Will the grammar allow for implicit returns in the manner of Ruby,
CoffeeScript. Seems to be the case for expression bodies. If multiple
statements are allowed (within block syntax) will implicit return apply to
the last statement or does explicit return become necessary?
3. Are parenthese required for zero arguments or will
let a = = doThis();
syntax be permitted (in line with CS)
thank you
Angus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Summary: prototypes as classes
I think its important to make a distinction between chained and unchained prototypes... By unchained prototypes I mean those that directly extend Object.prototype (note that that every built-in prototype specified by ES5 is unchained). Unchained prototypes are gorgeous - one instance defining the properties of many. And it's really not that hard...once you understand the difference between Constructor.prototype and instance.__proto__ (or its symbolic successor) you're all set. The concept itself is very simple - a dynamic archetype to be shared by all my instances: my prototype changes, my instances know about it. I would not want to hide such a smart, simple concept behind the more complex and (in this scenario) less meaningful concept of class. By chaining prototypes together we can mimic classical inheritance: objA - objA.prototype - objB.prototype - Object.prototype. As everyone knows prototype-chaining is non-trivial (though made easier by es5's Object.create) and this is the rationale for a class literal in es6: let the language absorb the complexity and let the engines make it faster. This would be fine and good if classical inheritance were a good fit for JavaScript, but I don't think it is: a) The syntax may be fixable but the logic isn't. Inheritance hierarchies are gnarly. - Nine times out of ten it's a re-use technique masquerading as a classification of types. Yes a shark is a fish (thanks @jb_briaud) and if you ever need a fish and a shark in your JavaScript then classical inheritance is for you. However if its re-use you want (and it almost always is) then implementation inheritance is tedious at best, a death-march at worst, because sooner or later the hierarchy becomes arbitrary and self defeating. Single-root trees are good for representing ancestry, I can attest that they are not good for defining re-use. - Even when the intention is to model relationships between types the process is awkward. Most types have multiple characteristics but classical JavaScript allows for only one parent. Moreover classical hierarchies must be implemented top-down - a superclass must be created before it can be extended - yet classes closer to the root are by nature more generic and abstract and are more easily defined *after* we have more knowledge of their concrete classes subclasses. Hierarchy definition is by necessity iterative which does not play well with an existing code base. b) JavaScript already has cleaner, lightweight, more flexible options: - Mixins allow objects to borrow from an unlimited number of other objects regardless of lineage, while still allowing for organization of functions by type. Mixins are way more flexible than inheritance chains - we can buy behavior types on demand with zero impact on the larger model. Prototypes facilitate Mixins, since a mixin is normally applied to an unchained prototype, another reason why new developers should continue to understand prototypes - 'class' is not a helpful concept where Mixins are concerned. - Delegation (call/apply) lets you grab any function whenever you need it. Classical Inheritance is necessary when your language constrains function usage by type hierarchy (Java, C++). JavaScript doesn't do this and doesn't need it. - The module pattern allows a chunk of data and functionality to be parceled into an object which can be used anywhere without compromising the integrity of the module's code. This ability to package up mini-eco-systems frees the developer from constraints of context that would occur if the same logic were defined as part of a class. c) How does the class concept square (no pun) with objects like Math, which is not a constructor and \therefore will not, I assume be considered a class? Is Math.pow a const now? If so how will that work when Math is not a class? If not that seems like an inconsistency. tl;dr Unchained prototypes: Invaluable concept; would be obfuscated by class syntax. Chained prototypes: Class literals might fix the syntax but the not the concept. JavaScript has better, easier tools already. --- I don't buy the argument (advanced by some in this discussion group) that as long as nothing is removed from the language, new features can't hurt. JavaScript has fewer keywords and a more lightweight syntax than almost any other mainstream language. For many of us that is hugely appealing and paradoxically it makes JavaScript enormously expressive. C++ syntax has everything but the kitchen sink (maybe that too) but as a language I suspect it bores most of use to sobs. Less is more. Earlier in this thread, Brendan said I claim we can do little to control the outcome in terms of adoption...the classical OOP patterning in many devs' brains, count more than our exhortations. That's sad because I think many ex-classical programmers (myself included) grew tired of implementation inheritance as the dominant paradigm and gravitated to JavaScript (and also functional languages) as a refuge from
Re: Is class syntax really necessary ?
Sugar is fine for defining classes (as opposed to defining types in terms of the constructor) but I get a little worried when I see the 'extends' keyword. I'm probably biased but I see many JavaScript trainees eager to simulate classical inheritance because it fits right in their comfort zone. It's been said a million times before but one of the most appealing characteristics of the JavaScript language is the availability of so many alternatives to rigid inheritance patterns (e.g. mixins, delegation, composition) which can liberate the developer from the confines of the traditional 'class' hierarchy and promote more flexible and readable code. If Dmitry is right in saying once class + extends is available everyone will just start to use it I'm concerned that this may be to the detriment of the language. thanks Angus On Mon, May 23, 2011 at 9:14 AM, Isaac Schlueter i...@izs.me wrote: On Mon, May 23, 2011 at 08:51, Brendan Eich bren...@mozilla.com wrote: Class syntax is like a lint brush for such features. If we add it, it will accrete more semantics (with unambiguous syntax, I hope) over time. This is just inevitable, in my view. It makes me want to resist classes and look at smaller and more direct fixes for the two known prototypal hazards. Yes, please! I assume two known hazards is referring to your previous email: subclassed prototype/constructor set-up and super calls. I've been using this pattern in my OOP javascript programs lately: https://github.com/isaacs/inherits/blob/master/inherits.js It works really well, behaves as expected (easy for the author to say, ha, but it doesn't violate instanceof, doesn't call ctors more than once, doesn't clobber already-added prototype properties, etc.) And it's about 10 lines, easy to read and grok. What would make it even nicer, however, with minimal added syntax: 1. Call super(a, b, c) instead of Child.super.call(this, a, b, c) 2. Maybe Parent.extend(Child) or Child.inherit(Parent) instead of inherits(Child, Parent) 3. Right now, calling parent versions of overridden methods is a painful: this.constructor.super.prototype.someMethod.call(this). It'd be nice to use something like super.someMethod(). ___ 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
