Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
Rick Waldron wrote:
On Monday, February 11, 2013, Nathan Wall wrote:
Thank you for this explanation. This is very interesting! If you
don't mind, I have some questions/concerns I'd like to clear up.
(In particular I want to make sure I understand; I don't intend to
argue for one side or the other ATM, but this change may require me
to refactor some old code to be future-ready).
Allen Wirfs-Brock wrote:
The choice we agreed to, at the meeting is
1) Array.prototype.map produces the same kind of array that it
was applied to, so:
for the above example
m instance of V will be true.
intArray.map(v=v.toSring()) produces an Int32Array. The strings
produced by the map function get converted back to numbers.
Sounds cool! Does it work?
I rely on the genericness of Array methods quite a lot. For example,
it's fairly common for me to write something like the following:
var map = Function.prototype.call.bind(Array.prototype.map),
select = document.querySelectorAll.bind(document);
var ids = map(select('div'), function(el) { return el.id
http://el.id; });
Currently this would get me an array of string ids for every div on
a page. In a future ES6 with a future DOM where NodeList extends
Array, will `ids` no longer hold an array of strings but try to
remain a NodeList?
There's a good chance this will break some of my code. I'm capable
of changing my code and writing this to be more future-friendly from
now on (I'm not one who prefers backwards compatibility over a
better language). But I would have always assumed I was doing things
correctly before, and I'm curious if the rest of the internet will
be okay..?
Since you're using Array.prototype.map there, your code will indeed give
you an array of string IDs, as it always did.
No it won't. In the current proposal (which I'd like to change, I think
Array is better default container for map), if NodeList would subclass
Array, applying (generic) Array.prototype.map on instance of NodeList
would create a new NodeList and would try to put ids on there.
Herby
Rick
Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit : All the presentation decks from the meeting are publicly available at http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013 the short form: In ES5, today you can use Array.prototype as the [[Prototype]] of non-Array objects or apply the Array.prototype methods to non-arrays. The behaviors they get are non-necessarily what you would expect if you would really subclass Array. We need to preserve the existing behaviors for these existing use cases but would like to provide the more reasonable behavior when class extends Array is used to create a subclass. Array.prototype.concat is the most problematic of the existing methods in this regard. After reading this thread and the slides, what is the plan for Typed Arrays (dedicated array like methods or Array subclassed like) ? I see the constraints for subclassing, but the solution a.from(b,map) seems a little bit strange (even if I agree that it should return the same instance as a) , and what about concat, slice, etc as you mention? Couldn't we add something like a parameter to the methods : example.map(f,thisArg, true) or example.map(f,true) returns example's instance instead of Array (same processing as .of, .from), so you can explicitely say that you want to return the same instance and don't have backward compatilities issues (hopefully...) ? I have used a lot Typed Arrays for [1] [2] [3] and all along wondering why Array like optimized methods were not available, especially concat, and why it was speced entirely in TC39 while a spec already exists (which specifies slice/subarray but surprisingly not concat), but it will be extremely usefull to have the Array like methods in the ES specs for Typed Arrays. Regards, [1] https://www.github.com/Ayms/node-Tor [2] https://www.github.com/Ayms/iAnonym [3] https://www.github.com/Ayms/node-typedarray -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms 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: bis - Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
and, I forgot and don't know exactly if this should fall here, a toString(encoding) method which supports streaming, see [3] using TextEncoder/TextDecoder Le 12/02/2013 12:54, Aymeric Vitte a écrit : Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit : All the presentation decks from the meeting are publicly available at http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013 the short form: In ES5, today you can use Array.prototype as the [[Prototype]] of non-Array objects or apply the Array.prototype methods to non-arrays. The behaviors they get are non-necessarily what you would expect if you would really subclass Array. We need to preserve the existing behaviors for these existing use cases but would like to provide the more reasonable behavior when class extends Array is used to create a subclass. Array.prototype.concat is the most problematic of the existing methods in this regard. After reading this thread and the slides, what is the plan for Typed Arrays (dedicated array like methods or Array subclassed like) ? I see the constraints for subclassing, but the solution a.from(b,map) seems a little bit strange (even if I agree that it should return the same instance as a) , and what about concat, slice, etc as you mention? Couldn't we add something like a parameter to the methods : example.map(f,thisArg, true) or example.map(f,true) returns example's instance instead of Array (same processing as .of, .from), so you can explicitely say that you want to return the same instance and don't have backward compatilities issues (hopefully...) ? I have used a lot Typed Arrays for [1] [2] [3] and all along wondering why Array like optimized methods were not available, especially concat, and why it was speced entirely in TC39 while a spec already exists (which specifies slice/subarray but surprisingly not concat), but it will be extremely usefull to have the Array like methods in the ES specs for Typed Arrays. Regards, [1] https://www.github.com/Ayms/node-Tor [2] https://www.github.com/Ayms/iAnonym [3] https://www.github.com/Ayms/node-typedarray -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms 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
A case for removing the seal/freeze/isSealed/isFrozen traps
Hi,
The main use case (correct me if I'm wrong) for freezing/sealing an
object is sharing an object to untrusted parties while preserving the
object integrity. There is also the tamper-proofing of objects everyone
has access to (Object.prototype in the browser)
In a world with proxies, it's easy to build new objects with high
integrity without Object.freeze: build your object, share only a wrapped
version to untrusted parties, the handler takes care of the integrity.
function thrower(){
throw new Error('nope');
}
var frozenHandler = {
set: thrower,
defineProperty: thrower,
delete: thrower
};
function makeFrozen(o){
return new Proxy(o, frozenHandler);
}
This is true to a point that I wonder why anyone would call
Object.freeze on script-created objects any longer... By design and for
good reasons, proxies are a subset of script-created objects, so my
previous sentence contained: I wonder why anyone would call
Object.freeze on proxies...
There were concerned about Object.freeze/seal being costly on proxies if
defined as preventExtension + enumerate + nbProps*defineProperty.
Assuming Object.freeze becomes de-facto deprecated in favor of
proxy-wrapping for high-integrity use cases, maybe that cost is not that
big of a deal.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
Loss of identity, extra allocations, and forwarding overhead remain
problems.
It seems to me that you are focusing too much on share ... to untrusted
parties. It's true you want either a membrane or an already-frozen
object in such a setting. But the latter case, already-frozen object,
does not want a membrane, both to avoid identity change and to avoid the
allocation and forwarding overheads. And outside of untrusted parties,
frozen objects have their uses -- arguably more over time with safe
parallelism in JS.
/be
David Bruant wrote:
Hi,
The main use case (correct me if I'm wrong) for freezing/sealing an
object is sharing an object to untrusted parties while preserving the
object integrity. There is also the tamper-proofing of objects
everyone has access to (Object.prototype in the browser)
In a world with proxies, it's easy to build new objects with high
integrity without Object.freeze: build your object, share only a
wrapped version to untrusted parties, the handler takes care of the
integrity.
function thrower(){
throw new Error('nope');
}
var frozenHandler = {
set: thrower,
defineProperty: thrower,
delete: thrower
};
function makeFrozen(o){
return new Proxy(o, frozenHandler);
}
This is true to a point that I wonder why anyone would call
Object.freeze on script-created objects any longer... By design and
for good reasons, proxies are a subset of script-created objects, so
my previous sentence contained: I wonder why anyone would call
Object.freeze on proxies...
There were concerned about Object.freeze/seal being costly on proxies
if defined as preventExtension + enumerate + nbProps*defineProperty.
Assuming Object.freeze becomes de-facto deprecated in favor of
proxy-wrapping for high-integrity use cases, maybe that cost is not
that big of a deal.
David
___
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
Class Method Syntax
First, thanks for creating a proposal for this. A couple of questions:
1) Is class method syntax slated for ES6?
2) I assume that we'd parse static the same way we parse get and
set, e.g. this is possible:
class C {
static() {} // Method static on C instance
static static() {} // Method static on C
}
Thanks!
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Private symbols vs property attributes
I have come to think that this distinction is backwards. It is
attributing something to symbols that actually is an attribute of
properties. Symbols are just symbols. We should not piggyback them
with something that is not actually related to their own semantics as
such, but only their forwarding in specific client contexts.
Agreed - thanks for sharing this perspective. I think that regardless of
what happens with respect to private state, we must only have one kind of
symbol.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Private symbols vs property attributes
On 10 February 2013 19:40, Mark Miller erig...@gmail.com wrote:
How does this interact with Proxies[1]? I know the answer probably starts
with whitelist, but let's spell it out in this context, and test it
against the 8 membrane transparency cases previously discussed. If there are
good answers for all of these, and if we can reuse enumerable: for this
purpose as Brendan suggests, then I'm guardedly positive. I do not want to
introduce a new attribute.
I must have missed the discussion of the 8 membrane transparency
cases. Do you have a pointer?
I'm fine with reusing 'enumerable'. Finally, a useful function for
that attribute. :)
/Andreas
[1] For now, I agree that the proxies we should examine are direct proxies.
On Sun, Feb 10, 2013 at 9:30 AM, David Bruant bruan...@gmail.com wrote:
Le 10/02/2013 17:16, Mark S. Miller a écrit :
I do not understand what is being proposed. When I try to imagine a
proposal starting from what has been said, I have not been able to imagine
something that works. But that's not a criticism. What is this alternate
privacy idea?
My understanding is:
* there is only one kind of symbol
* whether the symbol is reflected by Object.getOwnPropertyNames and the
likes is controlled by a 'private' attribute in property descriptors.
// unique constructor, no boolean since there is only one kind of
symbol
var s = new Symbol();
var o = {}, o2 = {};
Object.defineProperty(o, s, {value: 12, private: true});
assert(Object.getOwnPropertyNames(o).length === 0)
assert(o[s] === 12);
o[s] = 31;
assert(o[s] === 31);
Object.defineProperty(o2, s, {value: 7, private: false});
assert(Object.getOwnPropertyNames(o)[0] === s);
assert(o2[s] === 7);
o2[s] = 13;
assert(o2[s] === 13);
Pending question:
var o3 = {};
o3[s] = 62;
Object.getOwnPropertyDescriptor(o3, s).private // true or false?
Since private:false implies symbol sharing through
Object.getOwnPropertyDescriptor, I think private:true should be favored to
force people to be explicit (see my reply to Brendan)
The main difference with the current proposal is that privacy isn't an
inherent characteristic of the symbol, but related to how it's been
configured on the different objects it's been used on.
Was the above one of the things you imagined? If yes, why doesn't it work?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
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: Class Method Syntax
At the last TC39 meeting, Yehuda Katz presented a proposal that was
accepted for ES6:
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md#staticclass-side-methods
Rick
On Tue, Feb 12, 2013 at 9:44 AM, Kevin Smith khs4...@gmail.com wrote:
First, thanks for creating a proposal for this. A couple of questions:
1) Is class method syntax slated for ES6?
2) I assume that we'd parse static the same way we parse get and
set, e.g. this is possible:
class C {
static() {} // Method static on C instance
static static() {} // Method static on C
}
Thanks!
{ Kevin }
___
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: Private symbols vs property attributes
Le 12/02/2013 16:06, Andreas Rossberg a écrit : On 10 February 2013 19:40, Mark Miller erig...@gmail.com wrote: How does this interact with Proxies[1]? I know the answer probably starts with whitelist, but let's spell it out in this context, and test it against the 8 membrane transparency cases previously discussed. If there are good answers for all of these, and if we can reuse enumerable: for this purpose as Brendan suggests, then I'm guardedly positive. I do not want to introduce a new attribute. I must have missed the discussion of the 8 membrane transparency cases. Do you have a pointer? I think it is https://mail.mozilla.org/pipermail/es-discuss/2013-January/028481.html David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
[to limit the length of my reply, I had to avoid responding to every
detail, trying to answer the gist of your message instead; please let
me know if I missed anything important]
Of course, you might argue that I could just call it like:
NodeList.from( [ div, span, p ].map(nodeName =
document.createElement(nodeName)) );
Indeed, this would be my preferred choice. It would be more modular
than packaging the combination of container change and element
conversion into a single operation.
However, I understand the conflict between type-changing element
maps and element-type-constrained containers.
Let me change the example to bring out this point: if we convert from
an array of Int32 to an array of Double, we cannot map on the source
array nor can we map on the target array. So we do have to map the
elements in transit, after extracting them from the Int32 source and
before placing them in the Double target, preferably without creating
an intermediate Array.
Since the container change (.from()) is specced via iterators, I suggest
to ensure support for .map() on iterators and map the elements in the
iteration, after extraction from source, before integration into target.
Integrating the element map into the container conversion (.from())
instead, which is a static method to enforce target-type specification,
solves the issue you were trying to address, for Array subclasses, but
it leaves us with a host of residual issues:
- there are now two operations for one generic task,
Array.prototype.map( function )// type-preserving
TargetClass.from( source, function ) // type-changing
- the two -clearly related- operations do not have a common interface,
in fact, one is an object method, the other a static/class method
- the latter operation is really a family of operations, and the static
type prefixes of the family members are difficult to abstract over
(do I try to get the target type from the target object context or
from the function result, or do I force the user to pass it in at
every call site)
- even with this additional complexity, we still do not have support
for mapping over the elements of other, non-Array containers
I suspect that the problem of establishing target container types
is separate from the element mapping, so I would like to keep
.from() and .map() separate. But even in the merged design
programming will be awkward.
...But the arraylike or iterable might not have a .map() method
of its own, which will cause issues if I'm in a JS-target transpilation
scenario...
And I would like not only to root out any arraylike or iterable
that do not support .map(), but would also like to extend the reach
of .map() to other cases where it makes sense (I've listed examples
in previous messages).
(function( root ) {
root.converter = function( ctor, iterable, map ) {
return this[ ctor ].from( iterable, map );
}.bind(root);
}( this ));
What you're saying here is that (1) .from() should support .map()-like
functionality for all iterables (even if they do not support .map()), that
(2) we can't use .map() because it may not be supported for all iterables
and the 'map' parameter might be type-changing, and that (3) you
don't know how to get the target type generically, so it'll have to be
passed in at each call site.
None of this is promising when I think of writing generic code that
employs mapping over different container types, even if we assume
that the mapping .from() replaces .map() as the general interface.
Are you going to pass around 'ctor's as dynamic type hints? Since
we need the target classes, we can't even extract the class from
the source arrays. This, and the inability to de-structure things
like Int32Array into its components, are among the outstanding
language design issues generated in this area.
My point was that map is far more widely useful, not limited to
Array (Array.prototype.map), and not limited to Array construction
from Iterables (Array.prototype.from with second parameter).
Consider map on event emitters, on promises, on exceptions, on
generators, ..
I don't have an alternative solution that would cover all use cases
in ES uniformly, because the existing solutions in other languages
do not translate directly.
However, I wanted to ring a warning bell that adding a different
partial solution for every new use case is not going to scale well
(especially with things being so difficult to change once they are
in ES), and misses potential for writing generic library code.
Can you show an example of this?
Example of what (can't resolve 'this';-)? I listed several examples of
classes that I'd like to see map() support on. You gave an example
of how you couldn't write generic code using map() because not
all relevant classes support that method (using .from() on iterables
doesn't work, either). If you mean difficulties of evolving ES designs
after release, think no further than existing code
Re: Class Method Syntax
On Tue, Feb 12, 2013 at 9:44 AM, Kevin Smith khs4...@gmail.com wrote:
First, thanks for creating a proposal for this. A couple of questions:
1) Is class method syntax slated for ES6?
Yes.
2) I assume that we'd parse static the same way we parse get and set,
e.g. this is possible:
class C {
static() {} // Method static on C instance
static static() {} // Method static on C
}
Yes.
https://code.google.com/p/traceur-compiler/source/browse/test/feature/Classes/Static.js#23
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Class Method Syntax
Oooh, static getters and setters, nice.
Glad to see the max-min idea seems to be working out well :). Little
incremental improvements like this seem natural and a joy to use. Awesome to
see them in Traceur so quickly too!
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Tuesday, February 12, 2013 10:49
To: Kevin Smith
Cc: es-discuss
Subject: Re: Class Method Syntax
On Tue, Feb 12, 2013 at 9:44 AM, Kevin Smith khs4...@gmail.com wrote:
First, thanks for creating a proposal for this. A couple of questions:
1) Is class method syntax slated for ES6?
Yes.
2) I assume that we'd parse static the same way we parse get and set,
e.g. this is possible:
class C {
static() {} // Method static on C instance
static static() {} // Method static on C
}
Yes.
https://code.google.com/p/traceur-compiler/source/browse/test/feature/Classes/Static.js#23
--
erik
___
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: Private symbols vs property attributes
Andreas Rossberg wrote: I'm fine with reusing 'enumerable'. Finally, a useful function for that attribute.:) You and everyone else! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Class Method Syntax
Domenic Denicola wrote: Oooh, static getters and setters, nice. Glad to see the max-min idea seems to be working out well:). Little incremental improvements like this seem natural and a joy to use. Awesome to see them in Traceur so quickly too! Yes, this is great! All praise to Arv (and keep putting the C++ engines to shame ;-). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Private symbols vs property attributes
Yes. During a break at TC39 I sketched a very nice diagram of this to, IIRC, Rick. I stupidly did not take a photo. When I find the time I'll try to reproduce. In the meantime, hopefully the idea is clear enough. On Tue, Feb 12, 2013 at 7:23 AM, David Bruant bruan...@gmail.com wrote: Le 12/02/2013 16:06, Andreas Rossberg a écrit : On 10 February 2013 19:40, Mark Miller erig...@gmail.com wrote: How does this interact with Proxies[1]? I know the answer probably starts with whitelist, but let's spell it out in this context, and test it against the 8 membrane transparency cases previously discussed. If there are good answers for all of these, and if we can reuse enumerable: for this purpose as Brendan suggests, then I'm guardedly positive. I do not want to introduce a new attribute. I must have missed the discussion of the 8 membrane transparency cases. Do you have a pointer? I think it is https://mail.mozilla.org/**pipermail/es-discuss/2013-** January/028481.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2013-January/028481.html David -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minimal Module System Proposal
Kevin Smith wrote: Thanks, but let's not jump to any conclusions. I'm the champion of modules and wasn't even able to be a part of the discussion for family reasons. We can't make any judgment about the status of modules, or plans for reacting to the status of modules, before I've had a chance to be a part of the conversation. +1 and congrats (I'm slinging a babe right now ; ) I'm confident that modules will make it - in my mind ES6 will fail if not. They are certainly more important than proxies and private names, and the sooner we coalesce around the syntax, the better everyone will feel. IMO, your previous proposal was almost right on. e.g. http://wiki.ecmascript.org/doku.php?id=harmony:modulesrev=1332511079 http://wiki.ecmascript.org/doku.php?id=harmony:modulesrev=1332511079 https://gist.github.com/khs4473/4382710 I think we need to have a knock-down-drag-out discussion about URL and loader semantics. ; ) Question about the linked wiki page rev: Variant B: module = syntax Is that the variant you favor? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minimal Module System Proposal
Variant B: module = syntax
Is that the variant you favor?
Yes, because:
- It aligns the URL visually to the right, which is consistent with the
import syntax.
- It makes it clear that we are binding an identifier to a (possibly
external) module, as opposed to importing bindings from a module. I think
we should avoid overloaded terminology where import can also mean load.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minimal Module System Proposal
Kevin Smith wrote: Variant B: module = syntax Is that the variant you favor? Yes, because: - It aligns the URL visually to the right, which is consistent with the import syntax. - It makes it clear that we are binding an identifier to a (possibly external) module, as opposed to importing bindings from a module. I think we should avoid overloaded terminology where import can also mean load. I like it best too, for those reasons. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
