date:20130320

yes, SES, the non real world out there, needs __proto__ ... shenanigans all
over the world because of '__proto__' ain't important.

Thanks to be clear on it


On Wed, Mar 20, 2013 at 10:18 PM, Brendan Eich  wrote:

> Your writing is unclear and overlong, and full of unjustified airs of
> grievance -- please work on it.
>
> To recap yet again (last time): __proto__ is a de-facto standard we cannot
> defeat, whether anyone likes it or not. Adding Object.setPrototypeOf does
> not help, because code won't migrate to it completely so we'll be stuck
> with two APIs.
>
> If against all odds, all code everywhere *did* magically drop __proto__ in
> favor of Object.setPrototypeOf, then SES and similar subsets would be
> unable to protect secure code from ambient Object.setPrototypeOf usage from
> the insecure side on the secure side's objects, unless
> Object.setPrototypeOf were removed -- but that would break insecure-side
> code that reasonably (per your wishes) uses Object.setPrototypeOf in lieu
> of __proto__.
>
> Now do you understand?
>
> /be
>
> Andrea Giammarchi wrote:
>
>> never cared about IE much on mobile and I do not care about 100% or
>> __proto__ support ... there is 100% of Object.prototype pollution support
>> since ever and everybody knows that is a bad technique, specially done
>> through direct property rather than through a descriptor.
>>
>> What is the point then ? Should I feel free to shoot in my foot and in
>> all libraries foot because I can change even Object.prototype.__proto__ ? I
>> don't think so and I don't understand what is anyone point here.
>>
>> TC39 decided to do not even talk about __proto__ now is the best thing
>> ever to suggest and use because supported ... is not standard and loads of
>> shenanigans, is an undesired property full of undesired behaviors ... and
>> still you all are protecting it for which reason, exactly? Either you make
>> it standard, or you get rid of it ASAP allowing developers that use it
>> already to migrate, gracefully, through Object.setPrototypeOf ... and
>> considering setPrototypeOf, hidePrototypeOf, and freezePrototypeOf method
>> in ES7 ... how does that sound?
>>
>> 'cause otherwise we can just stop reading specs, if non standard stuff is
>> sacre more than specs and standards or potential, better, solutions.
>>
>> Best Regards
>>
>>
>>
>>
>>
>> On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron > waldron.r...@gmail.com**>> wrote:
>>
>>
>>
>>
>> On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi
>> > > >>
>>
>> wrote:
>>
>> I think zepto is using that to modify runtime NodeList results
>> after querySelectorAll but in any case it was not me saying
>> that __proto__ is used already. I use it only to shim
>> getPrototypeOf to be honest and I don't think is a good idea
>> to use it at all.
>>
>> My point is that Object.setPrototypeOf does not need a
>> property loads of shenanigans as __proto__ is so that no
>> Object.prototype.__proto__ would ever exist anywhere.
>>
>> I don't even know why that existed in first place,to be honest
>> ... so do not use it, pass through Object.setPrototypeOf, same
>> as you would suggest pass through Object.defineProperty
>> instead of using Object.prototype.__**defineGetter__
>> __defineSetters__, both "de facto standards" some time ago.
>>
>>
>> IE never implemented the __defineGetter__ __defineSetter__ but
>> they did implement the ES5 Object meta APIs and _are_ implementing
>> __proto__ for parity with browsers that currently support it—this
>> is the big difference. This is in addition to the rationale
>> recorded here
>> https://github.com/rwldrn/**tc39-notes/blob/master/es6/**
>> 2013-01/jan-29.md#45-why-**standardizing-on-__proto__-**
>> and-not-__definegsetter__-__**lookupgsetter__
>>
>> Rick
>>
>>
>>
>>
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto

Your writing is unclear and overlong, and full of unjustified airs of
grievance -- please work on it.

To recap yet again (last time): __proto__ is a de-facto standard we
cannot defeat, whether anyone likes it or not. Adding
Object.setPrototypeOf does not help, because code won't migrate to it
completely so we'll be stuck with two APIs.

If against all odds, all code everywhere *did* magically drop __proto__
in favor of Object.setPrototypeOf, then SES and similar subsets would be
unable to protect secure code from ambient Object.setPrototypeOf usage
from the insecure side on the secure side's objects, unless
Object.setPrototypeOf were removed -- but that would break insecure-side
code that reasonably (per your wishes) uses Object.setPrototypeOf in
lieu of __proto__.

Now do you understand?

/be

Andrea Giammarchi wrote:
never cared about IE much on mobile and I do not care about 100% or
__proto__ support ... there is 100% of Object.prototype pollution
support since ever and everybody knows that is a bad technique,
specially done through direct property rather than through a descriptor.

What is the point then ? Should I feel free to shoot in my foot and in
all libraries foot because I can change even
Object.prototype.__proto__ ? I don't think so and I don't understand
what is anyone point here.

TC39 decided to do not even talk about __proto__ now is the best thing
ever to suggest and use because supported ... is not standard and
loads of shenanigans, is an undesired property full of undesired
behaviors ... and still you all are protecting it for which reason,
exactly? Either you make it standard, or you get rid of it ASAP
allowing developers that use it already to migrate, gracefully,
through Object.setPrototypeOf ... and considering setPrototypeOf,
hidePrototypeOf, and freezePrototypeOf method in ES7 ... how does that
sound?

'cause otherwise we can just stop reading specs, if non standard stuff
is sacre more than specs and standards or potential, better, solutions.

Best Regards

On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron > wrote:

On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi
mailto:andrea.giammar...@gmail.com>>
wrote:

I think zepto is using that to modify runtime NodeList results
after querySelectorAll but in any case it was not me saying
that __proto__ is used already. I use it only to shim
getPrototypeOf to be honest and I don't think is a good idea
to use it at all.

My point is that Object.setPrototypeOf does not need a
property loads of shenanigans as __proto__ is so that no
Object.prototype.__proto__ would ever exist anywhere.

I don't even know why that existed in first place,to be honest
... so do not use it, pass through Object.setPrototypeOf, same
as you would suggest pass through Object.defineProperty
instead of using Object.prototype.__defineGetter__
__defineSetters__, both "de facto standards" some time ago.

IE never implemented the __defineGetter__ __defineSetter__ but
they did implement the ES5 Object meta APIs and _are_ implementing
__proto__ for parity with browsers that currently support it—this
is the big difference. This is in addition to the rationale
recorded here

https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__

Rick

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Comments on Refutable Patterns proposal

2013-03-20 Thread Axel Rauschmayer

http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching

- Would love to see examples for arrays. Especially if there are more element 
patterns (lhs) than array elements (rhs).

- Possible future extensions: Make pattern after "..." optional, allow "..." in 
the middle of an array. Examples:
let [...front, last] = someArray;
let [..., last] = someArray;
let [first, ...] = someArray;

- Missing parameter in third-last line?
Match(ElementPatterns, value, index, soft) =
   assert IsObject(value)
   case ElementPatterns of
  ElementPattern =>
 Match(ElementPattern, value, index, soft)
  ElementPattern "," ElementPatterns =>
 if Match(ElementPattern, value, index, soft) = SUCCESS then
Match(ElementPatterns, value, soft)   (* Missing? index+1 *)
 else
FAILURE

-- 
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: Patterns in parameter declarations: irrefutable?

2013-03-20 Thread Axel Rauschmayer

Thanks, didn’t know that applied to parameters, too. Then the following two 
functions are equivalent(?)

function (arg0, arg1, arg2) {
// ...
}
function (...args) {
let [arg0', arg1', arg2'] = args;
// ...
}

With the following rules for translating argi -> argi':
- paramName -> ?paramName
- pattern -> pattern (rest parameters, parameter default values, curly braces, 
square brackets)


On Mar 20, 2013, at 22:45 , Brendan Eich  wrote:

> The proposal we accepted, written by Andreas at 
> http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching, seems 
> clear. Patterns are refutable without an extra ? annotation. Andreas is using 
> prefix-?, note well.
> 
> /be
> 
> Axel Rauschmayer wrote:
>> Are patterns in parameter declarations irrefutable? In other words, given:
>> 
>>function foo({ opt1 }) { return opt1 }
>> 
>> What happens if we call foo()?
>>1. An exception is thrown
>>2. undefined is returned
>> I’d expect (2). If opt1 had a default value, I’d expect that value to be 
>> returned.
>> 
>> What happens if we call foo({})?
>>1. An exception is thrown
>>2. undefined is returned
>> 
>> I’m asking, because I’ve seen the pattern
>> 
>>function foo({ opt1 = 3 } = {}) { return opt1 }
>> 
>> If explicitly marking something as irrefutable is necessary, I’d prefer:
>> 
>>function foo({ opt1 = 3 }?) { return opt1 }
>> 
>> 
>> It’s a bit of a shame that destructuring and parameter declarations diverge, 
>> but I guess it can’t be helped.

-- 
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: Observability of NaN distinctions — is this a concern?


On Mar 20, 2013, at 2:38 PM, Kenneth Russell wrote:
>> 
> 
> The typed array specification in its original form deliberately
> avoided specifying normalization of NaNs upon writes to Float32Array
> and Float64Array. Doing so has no practical value and only imposes a
> performance hit, which is unacceptable for applications trying to
> reach the highest possible performance.
> 
> I hope that the ES6 integration of typed arrays will not require
> normalization of NaNs on write, even if other specification changes
> need to be made to avoid requiring it.
> 

Here is the exact language that is in the current ES6 draft for storing a 
Number into a buffer as a Float64 (rawValue is the value that gets stored into 
the buffer):

Set rawValue to the 8 bytes that are the IEEE-868-2005 binary64 format encoding 
of value. If isBigEndian is true, the bytes are arranged in big endian order.  
Otherwise, the bytes are arranged in little endian order.  If value is NaN, 
rawValue is may be set to any implementation choosen non-signaling NaN encoding.

Allen


> -Ken
> 
> 
>> _Incidentally_, I observe that normalization on read is not necessary except
>> as an implementation strategy. It may well be that all implementations will
>> find it expedient, but there is no need for the spec to require it, since
>> (as 8.1.5 specifically acknowledges) an implementation may choose to let the
>> NaN bits vary, as long as all operations on them (which includes
>> SetValueInBuffer by my above argument) treat them identically.
>> 
>> 
>> ___
>> 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: Patterns in parameter declarations: irrefutable?

The proposal we accepted, written by Andreas at 
http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching, seems 
clear. Patterns are refutable without an extra ? annotation. Andreas is 
using prefix-?, note well.


/be

Axel Rauschmayer wrote:
Are patterns in parameter declarations irrefutable? In other words, 
given:


function foo({ opt1 }) { return opt1 }

What happens if we call foo()?
1. An exception is thrown
2. undefined is returned
I’d expect (2). If opt1 had a default value, I’d expect that value to 
be returned.


What happens if we call foo({})?
1. An exception is thrown
2. undefined is returned

I’m asking, because I’ve seen the pattern

function foo({ opt1 = 3 } = {}) { return opt1 }

If explicitly marking something as irrefutable is necessary, I’d prefer:

function foo({ opt1 = 3 }?) { return opt1 }


It’s a bit of a shame that destructuring and parameter declarations 
diverge, but I guess it can’t be helped.


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: Observability of NaN distinctions — is this a concern?

2013-03-20 Thread Kenneth Russell

On Wed, Mar 20, 2013 at 2:24 PM, Kevin Reid  wrote:
> On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock 
> wrote:
>>
>> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
>>>
>>> That normalization on read is is my case 1 above — it is necessary _for
>>> that implementation_. A conformant implementation could use a different
>>> strategy which does not normalize on Float64 read, and this would be
>>> unobservable, so the spec should not bother to specify it.
>>>
>>> However, lack of normalization on Float64 write _is_ potentially
>>> observable (if the implementation does not normalize all NaNs from all
>>> sources). Therefore, I argue, the spec should specify that normalization
>>> happens on write; and it happens that an implementation can omit that as an
>>> explicit step, with no observable difference, if and only if its
>>> representation of NaN in JS values (from all possible sources, not just
>>> typed arrays) is normalized.
>>
>>
>> The buffer contents may have come form an external source or the buffer
>> may be accessible for writes by an agent that is not part of the ES
>> implementation.  The only thing that the ES implementation has absolute
>> control over are its own reads from a buffer and the values it propagates
>> from those reads.
>
>
> I don't think we're disagreeing about any facts or principles (everything in
> your paragraph above is true), but you're thinking about implementation
> strategies and I'm thinking about observable behavior.
>
> This is the important point: normalization on write _or
> observably-equivalent behavior_ is implicitly mandatory because otherwise
> 8.1.5 may fail to hold (standard ES code can use standard ES tools to
> distinguish NaNs, as demonstrated by my test results — the behavior I found
> does not contradict the spec, to my knowledge). Therefore, the spec should
> not claim that it is optional.

The typed array specification in its original form deliberately
avoided specifying normalization of NaNs upon writes to Float32Array
and Float64Array. Doing so has no practical value and only imposes a
performance hit, which is unacceptable for applications trying to
reach the highest possible performance.

I hope that the ES6 integration of typed arrays will not require
normalization of NaNs on write, even if other specification changes
need to be made to avoid requiring it.

-Ken


> _Incidentally_, I observe that normalization on read is not necessary except
> as an implementation strategy. It may well be that all implementations will
> find it expedient, but there is no need for the spec to require it, since
> (as 8.1.5 specifically acknowledges) an implementation may choose to let the
> NaN bits vary, as long as all operations on them (which includes
> SetValueInBuffer by my above argument) treat them identically.
>
>
> ___
> 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: Observability of NaN distinctions — is this a concern?

2013-03-20 Thread Kevin Reid

On Wed, Mar 20, 2013 at 1:57 PM, Allen Wirfs-Brock wrote:

> On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:

 That normalization on read is is my case 1 above — it is necessary _for
>> that implementation_. A conformant implementation could use a different
>> strategy which does not normalize on Float64 read, and this would be
>> unobservable, so the spec should not bother to specify it.
>>
>> However, lack of normalization on Float64 write _is_ potentially
>> observable (if the implementation does not normalize all NaNs from all
>> sources). Therefore, I argue, the spec should specify that normalization
>> happens on write; and it happens that an implementation can omit that as an
>> explicit step, with no observable difference, if and only if its
>> representation of NaN in JS values (from all possible sources, not just
>> typed arrays) is normalized.
>
>
> The buffer contents may have come form an external source or the buffer
> may be accessible for writes by an agent that is not part of the ES
> implementation.  The only thing that the ES implementation has absolute
> control over are its own reads from a buffer and the values it propagates
> from those reads.

I don't think we're disagreeing about any facts or principles (everything
in your paragraph above is true), but you're thinking about implementation
strategies and I'm thinking about observable behavior.

This is the important point: normalization on write _or
observably-equivalent behavior_ is implicitly mandatory because otherwise 8.1.5
may fail to hold (standard ES code can use standard ES tools to distinguish
NaNs, as demonstrated by my test results — the behavior I found does not
contradict the spec, to my knowledge). Therefore, the spec should not claim
that it is optional.

_Incidentally_, I observe that normalization on read is not necessary
except as an implementation strategy. It may well be that all
implementations will find it expedient, but there is no need for the spec
to require it, since (as 8.1.5 specifically acknowledges) an implementation
may choose to let the NaN bits vary, as long as all operations on them
(which includes SetValueInBuffer by my above argument) treat them
identically.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto

never cared about IE much on mobile and I do not care about 100% or
__proto__ support ... there is 100% of Object.prototype pollution support
since ever and everybody knows that is a bad technique, specially done
through direct property rather than through a descriptor.

What is the point then ? Should I feel free to shoot in my foot and in all
libraries foot because I can change even Object.prototype.__proto__ ? I
don't think so and I don't understand what is anyone point here.

TC39 decided to do not even talk about __proto__ now is the best thing ever
to suggest and use because supported ... is not standard and loads of
shenanigans, is an undesired property full of undesired behaviors ... and
still you all are protecting it for which reason, exactly? Either you make
it standard, or you get rid of it ASAP allowing developers that use it
already to migrate, gracefully, through Object.setPrototypeOf ... and
considering setPrototypeOf, hidePrototypeOf, and freezePrototypeOf method
in ES7 ... how does that sound?

'cause otherwise we can just stop reading specs, if non standard stuff is
sacre more than specs and standards or potential, better, solutions.

Best Regards

On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron wrote:

>
>
>
> On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I think zepto is using that to modify runtime NodeList results after
>> querySelectorAll but in any case it was not me saying that __proto__ is
>> used already. I use it only to shim getPrototypeOf to be honest and I don't
>> think is a good idea to use it at all.
>>
>> My point is that Object.setPrototypeOf does not need a property loads of
>> shenanigans as __proto__ is so that no Object.prototype.__proto__ would
>> ever exist anywhere.
>>
>> I don't even know why that existed in first place,to be honest ... so do
>> not use it, pass through Object.setPrototypeOf, same as you would suggest
>> pass through Object.defineProperty instead of using
>> Object.prototype.__defineGetter__ __defineSetters__, both "de facto
>> standards" some time ago.
>>
>
> IE never implemented the __defineGetter__ __defineSetter__ but they did
> implement the ES5 Object meta APIs and _are_ implementing __proto__ for
> parity with browsers that currently support it—this is the big difference.
> This is in addition to the rationale recorded here
> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__
>
> Rick
>
>
>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?


On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:

> 
> That normalization on read is is my case 1 above — it is necessary _for that 
> implementation_. A conformant implementation could use a different strategy 
> which does not normalize on Float64 read, and this would be unobservable, so 
> the spec should not bother to specify it.
> 
> However, lack of normalization on Float64 write _is_ potentially observable 
> (if the implementation does not normalize all NaNs from all sources). 
> Therefore, I argue, the spec should specify that normalization happens on 
> write; and it happens that an implementation can omit that as an explicit 
> step, with no observable difference, if and only if its representation of NaN 
> in JS values (from all possible sources, not just typed arrays) is normalized.

The buffer contents may have come form an external source or the buffer may be 
accessible for writes by an agent that is not part of the ES implementation.  
The only thing that the ES implementation has absolute control over are its own 
reads from a buffer and the values it propagates from those reads.

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?

2013-03-20 Thread Kevin Reid

On Wed, Mar 20, 2013 at 12:56 PM, Allen Wirfs-Brock
wrote:

>
> If you're specifically talking about reading/writing TypedArray elements
> (really ArrayBuffers) you have to take into account the possibility that
> you can have different types overlaying the same buffer storage.
>

Yes, that was my original example.

>   Hence a NaN bit pattern might be written as 2 Uint32 values and then
> retrieved as a Float64 value.  In that case, there is no Float64 write to
> perform the normalization so it must be done on all reads. Such
> normalization is especially important if object pointers are represented
> using  NaN-boxing.
>

That normalization on read is is my case 1 above — it is necessary _for
that implementation_. A conformant implementation could use a different
strategy which does not normalize on Float64 read, and this would be
unobservable, so the spec should not bother to specify it.

However, lack of normalization on Float64 write _is_ potentially observable
(if the implementation does not normalize all NaNs from all sources).
Therefore, I argue, the spec should specify that normalization happens on
write; and it happens that an implementation can omit that as an explicit
step, with no observable difference, if and only if its representation of
NaN in JS values (from all possible sources, not just typed arrays) is
normalized.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto

2013-03-20 Thread Rick Waldron

On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I think zepto is using that to modify runtime NodeList results after
> querySelectorAll but in any case it was not me saying that __proto__ is
> used already. I use it only to shim getPrototypeOf to be honest and I don't
> think is a good idea to use it at all.
>
> My point is that Object.setPrototypeOf does not need a property loads of
> shenanigans as __proto__ is so that no Object.prototype.__proto__ would
> ever exist anywhere.
>
> I don't even know why that existed in first place,to be honest ... so do
> not use it, pass through Object.setPrototypeOf, same as you would suggest
> pass through Object.defineProperty instead of using
> Object.prototype.__defineGetter__ __defineSetters__, both "de facto
> standards" some time ago.
>

IE never implemented the __defineGetter__ __defineSetter__ but they did
implement the ES5 Object meta APIs and _are_ implementing __proto__ for
parity with browsers that currently support it—this is the big difference.
This is in addition to the rationale recorded here
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__

Rick

>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?

2013-03-20 Thread Brandon Benvie


On 3/20/2013 12:56 PM, Allen Wirfs-Brock wrote:
If you're specifically talking about reading/writing TypedArray 
elements (really ArrayBuffers) you have to take into account the 
possibility that you can have different types overlaying the same 
buffer storage.  Hence a NaN bit pattern might be written as 2 Uint32 
values and then retrieved as a Float64 value.  In that case, there is 
no Float64 write to perform the normalization so it must be done on 
all reads.  Such normalization is especially important if object 
pointers are represented using  NaN-boxing.


Allen
Exactly, you can't control it on the write end. Writing two uint32's is 
precisely how you do NaN-tagging using typed arrays (since you can't 
write an uint64). The way to normalize is to coerce to a single 
canonical NaN on read, if anything.


(an example of NaN-tagging using typed arrays: 
https://gist.github.com/Benvie/5021724)

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Mutable Proto

2013-03-20 Thread Nathan Wall

David Bruant wrote:
> Le 20/03/2013 16:36, Nathan Wall a écrit :
>> I didn't get a direct response to my question about mutating proto on 
>> objects which don't inherit from Object.prototype, but I'm inferring from 
>> [1] that it won't be possible. I find this unfortunate, but I realize this 
>> issue has seen a lot of discussion in the past and there are reasons for the 
>> current decision. I will see how I can make my code cope with reality.
> Could you describe how you use __proto__ on objects not inheriting from
> Object.prototype?
>
> From what I know there are 2 main use cases:
> 1) object as map
> changing the prototype enable changing different "default values". I
> guess any solution to that problem either looses the object syntax
> (maybe unless using proxies) like using an ES6 Map or has non-trivial
> runtime cost.
> Or the code needs to be reorganized so that the object is always created
> after the prototype (using Object.create for instance)
>
> 2) Subclassing
> ES6 will have classes with inheritance. That's mostly syntax sugar on
> top of what's already possible, but that works.
>
> Do you have a use case that belongs in neither of these categories?

Hi David.

I would add (3) Integrity/Security. When you don't want mucking with 
`Object.prototype` to be able to influence a script.

My current use-case has to do with shimming private properties into ES5. It may 
be something I want to continue doing in ES6 depending on how private 
properties are implemented in ES6.  The full working library is available at 
https://github.com/Nathan-Wall/Secrets

Let me explain the relevant portions for why I want mutable proto on objects 
which don't inherit from Object.prototype.

Take this simple, highly contrived example:

    var apple, grannySmith;
    (function() {

        var priv = createSecret();

        apple = {
            get foodType() { return priv(this).foodType; },
            get color() { return priv(this).color; },
            toString: function() { return this.color + ' ' + this.foodType; }
        };

        priv(apple).foodType = 'fruit';
        priv(apple).color = 'red';

        grannySmith = Object.create(apple);

        priv(grannySmith).color = 'green';

    })();

    apple.toString();       // => 'red fruit'
    grannySmith.toString(); // => 'green fruit'

In ES5 Secrets works by overriding `Object.getOwnPropertyNames` to hide a 
secret property. In ES6, this could work using `makePrivate`, WeakMaps, or 
whatever mechanisms are available to create private state.

`priv` is a function which returns an object which represents the private state 
of any object.

The important part is that in order for the above to work, secrets need to 
respect prototypal inheritance.  When `grannySmith.toString` is called, it 
calls `grannySmith.foodType`, which accesses the "private" `foodType` property. 
Since `grannySmith` doesn't have a `foodType` property on its private object, 
it should look up the inheritance chain for `apple`'s `foodType` private 
property.

The following code snip shows how this is set up for the non-mutable proto case:

(In the following code `create = Object.create` and `getPrototypeOf = 
Object.getPrototypeOf`.)

    function createSecret() {

        var id = nextUniqueId();

        return function secret(obj) {
            var S, proto, protoS, protoSTest,
                // This function generates an object which is stored on a 
hidden property of `obj`.
                secrets = Secrets(obj)
            if (secrets) {
                // The id is used to distinguish between different secret 
functions.
                S = secrets[id];
                if (!S) {
                    proto = getPrototypeOf(obj);
                    // Create a new object which inherits from the secret of 
obj's prototype.
                    secrets[id] = S = create(proto ? secret(proto) : null);
                }
                return S;
            } else
                // The object may have been frozen in another frame.
                throw new Error('This object doesn\'t support secrets.');
        };

    }

As you can see, the private objects inherit from other private objects which 
eventually inherit from null. For instance:

    var A = { };
    var B = Object.create(A);
    var C = Object.create(B);

    var priv = createSecret();

    var privC = priv(C);

C's prototype chain looks like:

    null -> Object.prototype -> A -> B -> C

so privC's prototype chain looks like:

    null -> priv(Object.prototype) -> priv(A) -> priv(B) -> priv(C)

where `priv(X)` is the private object used to store the private state of X.

In order to get this to work for mutable proto, the private objects need to 
change their prototypes whenever the public object changes its prototype.

    var D = { };
    C.__proto__ = D;
    // C's new prototype chain:
    //    null -> Object.prototype -> D -> C

So we need to change priv(C)'s prototype chain to match.

But priv(C) s

Re: Observability of NaN distinctions — is this a concern?


On Mar 20, 2013, at 12:34 PM, Kevin Reid wrote:

> On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock  
> wrote:
> On Mar 20, 2013, at 10:09 AM, Kevin Reid wrote:
> 
> > Depending on what you mean by “ECMAScript code”, this may be false given 
> > the Typed Arrays extension, which allows direct access to the bit-patterns 
> > of float values (the Typed Arrays spec permits, but does not require, 
> > replacing a NaN value with any other NaN value on read or write).
> 
> This is not how it is specified in the ES6 spec. See 15.13.5.1.3 steps 7.b & 
> 8.b and 15.13.5.1.4 steps 7.a & 8.a.  Normalization of NaN values is required 
> on retrieval and permitted on stores form/to ArrayBuffers.
> 
> I see. I was reading the Khronos version and hadn't realized it was included 
> in ES6.
> 
> The ES spec. requirement (which isn't new to ES6) still applies.  If they 
> expose observably different NaN values to any ECMAScript code they aren't 
> conforming to the spec.
> 
> Then it seems to me that the wording of the spec, while not 
> self-contradictory, makes it unnecessarily unobvious how to correctly 
> implement it. Consider these two cases (which I think are exhaustive):
> 
> 1. The implementation uses exactly one bit pattern for JS values which are 
> NaN. In this case, normalization is required on reads and is a no-op for 
> writes.
> 
> 2. The implementation represents JS values which are NaN using arbitrary NaN 
> bit patterns (and SameValue considers them all equal). In this case, 
> normalization is unnecessary for reads and necessary for writes (else, as my 
> example code shows, the difference is observable which contradicts 8.1.5).
> 
> Thus, normalization on write is either a no-op or necessary, so should be 
> mandatory, and normalization on read is unobservable in either case, so need 
> not be mandatory.

If you're specifically talking about reading/writing TypedArray elements 
(really ArrayBuffers) you have to take into account the possibility that you 
can have different types overlaying the same buffer storage.  Hence a NaN bit 
pattern might be written as 2 Uint32 values and then retrieved as a Float64 
value.  In that case, there is no Float64 write to perform the normalization so 
it must be done on all reads.  Such normalization is especially important if 
object pointers are represented using  NaN-boxing.

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Patterns in parameter declarations: irrefutable?

2013-03-20 Thread Axel Rauschmayer

Are patterns in parameter declarations irrefutable? In other words, given:

function foo({ opt1 }) { return opt1 }

What happens if we call foo()?
1. An exception is thrown
2. undefined is returned
I’d expect (2). If opt1 had a default value, I’d expect that value to be 
returned.

What happens if we call foo({})?
1. An exception is thrown
2. undefined is returned

I’m asking, because I’ve seen the pattern

function foo({ opt1 = 3 } = {}) { return opt1 }

If explicitly marking something as irrefutable is necessary, I’d prefer:

function foo({ opt1 = 3 }?) { return opt1 }


It’s a bit of a shame that destructuring and parameter declarations diverge, 
but I guess it can’t be helped.

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

Re: Mutable Proto

I think zepto is using that to modify runtime NodeList results after
querySelectorAll but in any case it was not me saying that __proto__ is
used already. I use it only to shim getPrototypeOf to be honest and I don't
think is a good idea to use it at all.

My point is that Object.setPrototypeOf does not need a property loads of
shenanigans as __proto__ is so that no Object.prototype.__proto__ would
ever exist anywhere.

I don't even know why that existed in first place,to be honest ... so do
not use it, pass through Object.setPrototypeOf, same as you would suggest
pass through Object.defineProperty instead of using
Object.prototype.__defineGetter__ __defineSetters__, both "de facto
standards" some time ago.

So, reverting the question, what is **your** point saying that __proto__ is
better than Object.setPrototypeOf ?

Regards

On Wed, Mar 20, 2013 at 12:22 PM, David Bruant  wrote:

>  Le 20/03/2013 19:04, Andrea Giammarchi a écrit :
>
> I don't understand where is the problem ... any library that uses
> __proto__ can and should be updated with a shim waiting for next version of
> JS to support it.
>
> Which library? What are the inconsistencies between the current __proto__
> draft spec and how libraries use __proto__ today? Please be very specific;
> that's quite relevant when doing a de facto standard so it's important to
> know.
>
>
>  Object.setPrototypeOf = function (object, proto) {
>   object.__proto__ = proto;
>   return object;
> };
>
>  That does not look bad at all to me, educate developers out there that
> __proto__ is harmful and forbidden 'cause saying "we can't do much is
> already used" doesn't mean is OK to use it, same as polluting
> Object.prototype, still possible, nobody does it (not in an old fashioned
> way at least)
>
> What's your point here?
> I don't understand why Object.setPrototypeOf should be added or shimmed if
> the best practice is to avoid using __proto__.
>
> David
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?

2013-03-20 Thread Kevin Reid

On Wed, Mar 20, 2013 at 12:10 PM, Allen Wirfs-Brock
wrote:

> On Mar 20, 2013, at 10:09 AM, Kevin Reid wrote:
>
> > Depending on what you mean by “ECMAScript code”, this may be false given
> the Typed Arrays extension, which allows direct access to the bit-patterns
> of float values (the Typed Arrays spec permits, but does not require,
> replacing a NaN value with any other NaN value on read or write).
>
> This is not how it is specified in the ES6 spec. See 15.13.5.1.3 steps 7.b
> & 8.b and 15.13.5.1.4 steps 7.a & 8.a.  Normalization of NaN values is
> required on retrieval and permitted on stores form/to ArrayBuffers.
>

I see. I was reading the Khronos version and hadn't realized it was
included in ES6.

The ES spec. requirement (which isn't new to ES6) still applies.  If they
> expose observably different NaN values to any ECMAScript code they aren't
> conforming to the spec.

Then it seems to me that the wording of the spec, while not
self-contradictory, makes it unnecessarily unobvious how to correctly
implement it. Consider these two cases (which I think are exhaustive):

1. The implementation uses exactly one bit pattern for JS values which are
NaN. In this case, normalization is required on reads and is a no-op for
writes.

2. The implementation represents JS values which are NaN using arbitrary
NaN bit patterns (and SameValue considers them all equal). In this case,
normalization is unnecessary for reads and necessary for writes (else, as
my example code shows, the difference is observable which contradicts
8.1.5).

Thus, normalization on write is either a no-op or necessary, so should be
mandatory, and normalization on read is unobservable in either case, so
need not be mandatory.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?


Le 20/03/2013 19:08, Jeff Walden a écrit :

I don't see what can reasonably be done about it, without effectively mandating 
attempting NaN-substitution whenever the value to set might be NaN.

+1. I think Safari needs to be fixed.
Stuffing info in NaNs sounds superfluous. JS has objects, arrays, Typed 
Arrays, strings. Largely enough legitimate mechanisms to represent 
informations without having to add a hacky one. That would be sending a 
wrong signal to developers in my opinion.


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto


Le 20/03/2013 19:04, Andrea Giammarchi a écrit :
I don't understand where is the problem ... any library that uses 
__proto__ can and should be updated with a shim waiting for next 
version of JS to support it.
Which library? What are the inconsistencies between the current 
__proto__ draft spec and how libraries use __proto__ today? Please be 
very specific; that's quite relevant when doing a de facto standard so 
it's important to know.



Object.setPrototypeOf = function (object, proto) {
object.__proto__ = proto;
  return object;
};

That does not look bad at all to me, educate developers out there that 
__proto__ is harmful and forbidden 'cause saying "we can't do much is 
already used" doesn't mean is OK to use it, same as polluting 
Object.prototype, still possible, nobody does it (not in an old 
fashioned way at least)

What's your point here?
I don't understand why Object.setPrototypeOf should be added or shimmed 
if the best practice is to avoid using __proto__.


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?

On Mar 20, 2013, at 11:08 AM, Jeff Walden wrote:

> Negation on at least some x86-ish systems also produces another kind of NaN, 
> because the trivial negation implementation is a sign-bit flip.
> 
> This strikes me as similar to the endianness concerns of typed arrays, except 
> probably far less harmful in practice.  I don't see what can reasonably be 
> done about it, without effectively mandating attempting NaN-substitution 
> whenever the value to set might be NaN.  But maybe someone smarter has ideas.

It simple, all isNaN testing and all places that perform "pointer equivalent" 
tests must treat all NaN values as equivalent.   An implementation  either must 
guarantee normalization or NaNs or explicitly check for non identical NaN bit 
patterns.

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?

2013-03-20 Thread Jeff Walden

Negation on at least some x86-ish systems also produces another kind of NaN, 
because the trivial negation implementation is a sign-bit flip.

This strikes me as similar to the endianness concerns of typed arrays, except 
probably far less harmful in practice.  I don't see what can reasonably be done 
about it, without effectively mandating attempting NaN-substitution whenever 
the value to set might be NaN.  But maybe someone smarter has ideas.

Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto

I don't understand where is the problem ... any library that uses __proto__
can and should be updated with a shim waiting for next version of JS to
support it.

Object.setPrototypeOf = function (object, proto) {
  object.__proto__ = proto;
  return object;
};

That does not look bad at all to me, educate developers out there that
__proto__ is harmful and forbidden 'cause saying "we can't do much is
already used" doesn't mean is OK to use it, same as polluting
Object.prototype, still possible, nobody does it (not in an old fashioned
way at least)

Best Regards




On Wed, Mar 20, 2013 at 9:27 AM, David Bruant  wrote:

> Le 20/03/2013 16:15, Brendan Eich a écrit :
>
>> To recap,
>>
>> 1. __proto__ is out in the field, a de-facto standard on "mobile", and
>> not going away. Adding another API doesn't help, it hurts.
>>
>> 2. SES and other secure subsets want same-frame (global object, "realm")
>> mashups of code that may use __proto__ and code that must not, but
>> Object.setPrototypeOf is a per-frame capability that would have to be
>> removed, breaking the former class of code.
>>
>> (...)
>>
>>
>> Yes, the problems you cite are real, but they are already part of the
>> de-facto __proto__ standard (1).
>>
> Agreed.
> From the spec/implementor point of view, __proto__ has to be added as
> de-facto standard because it is used.
> From the developer point of view, it is not because it's in the language
> that it's a good idea to use it. Quite the opposite, I'd like to reiterate
> that devs should make "delete Object.prototype.__proto__" the second line
> of their code (first line is "use strict";).
> Devs shouldn't make the mistake to think that __proto__ in the standard
> makes it a good or legitimate feature.
>
> __proto__ in ES6 is yet another ECMAScript Regret [1]
>
> David
>
> [1] 
> https://github.com/**DavidBruant/ECMAScript-regrets(I
>  haven't found much time to write more, but issues are more interesting
> to read than just the part that's been written down)
>
> __**_
> 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: Mutable Proto


Le 20/03/2013 16:15, Brendan Eich a écrit :

To recap,

1. __proto__ is out in the field, a de-facto standard on "mobile", and 
not going away. Adding another API doesn't help, it hurts.


2. SES and other secure subsets want same-frame (global object, 
"realm") mashups of code that may use __proto__ and code that must 
not, but Object.setPrototypeOf is a per-frame capability that would 
have to be removed, breaking the former class of code.


(...)

Yes, the problems you cite are real, but they are already part of the 
de-facto __proto__ standard (1).

Agreed.
From the spec/implementor point of view, __proto__ has to be added as 
de-facto standard because it is used.
From the developer point of view, it is not because it's in the 
language that it's a good idea to use it. Quite the opposite, I'd like 
to reiterate that devs should make "delete Object.prototype.__proto__" 
the second line of their code (first line is "use strict";).
Devs shouldn't make the mistake to think that __proto__ in the standard 
makes it a good or legitimate feature.


__proto__ in ES6 is yet another ECMAScript Regret [1]

David

[1] https://github.com/DavidBruant/ECMAScript-regrets (I haven't found 
much time to write more, but issues are more interesting to read than 
just the part that's been written down)

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto


Le 20/03/2013 16:36, Nathan Wall a écrit :

I didn't get a direct response to my question about mutating proto on objects 
which don't inherit from Object.prototype, but I'm inferring from [1] that it 
won't be possible.  I find this unfortunate, but I realize this issue has seen 
a lot of discussion in the past and there are reasons for the current decision. 
 I will see how I can make my code cope with reality.
Could you describe how you use __proto__ on objects not inheriting from 
Object.prototype?


From what I know there are 2 main use cases:
1) object as map
changing the prototype enable changing different "default values". I 
guess any solution to that problem either looses the object syntax 
(maybe unless using proxies) like using an ES6 Map or has non-trivial 
runtime cost.
Or the code needs to be reorganized so that the object is always created 
after the prototype (using Object.create for instance)


2) Subclassing
ES6 will have classes with inheritance. That's mostly syntax sugar on 
top of what's already possible, but that works.


Do you have a use case that belongs in neither of these categories?

David



Nathan


Brendan Eich wrote:

Mariusz Nowak wrote:

+1!

It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.

We've been over this many times, e.g. at

https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html

To recap,

1. __proto__ is out in the field, a de-facto standard on "mobile", and
not going away. Adding another API doesn't help, it hurts.

2. SES and other secure subsets want same-frame (global object, "realm")
mashups of code that may use __proto__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.



Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).

No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.


Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].

Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.

Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Mutable Proto

2013-03-20 Thread Nathan Wall

I didn't get a direct response to my question about mutating proto on objects 
which don't inherit from Object.prototype, but I'm inferring from [1] that it 
won't be possible.  I find this unfortunate, but I realize this issue has seen 
a lot of discussion in the past and there are reasons for the current decision. 
 I will see how I can make my code cope with reality.

Nathan


Brendan Eich wrote:
> Mariusz Nowak wrote:
> > +1!
> >
> > It would be great if someone will explain in detail why
> > Object.setPrototypeOf is no go.
>
> We've been over this many times, e.g. at
>
> https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
>
> To recap,
>
> 1. __proto__ is out in the field, a de-facto standard on "mobile", and
> not going away. Adding another API doesn't help, it hurts.
>
> 2. SES and other secure subsets want same-frame (global object, "realm")
> mashups of code that may use __proto__ and code that must not, but
> Object.setPrototypeOf is a per-frame capability that would have to be
> removed, breaking the former class of code.
>
>
> > Any function that blindly extends object with provided hash is affected e.g.
> > extend(obj, { __proto__: Error.prototype }).
>
> No, that depends on how extend works. If it uses Object.defineProperty
> or equivalent, then nothing is broken and the setter on Object.prototype
> for __proto__ is not run.
>
> > Additionally it means that we need to serialize any user input which
> > eventually may be used as key on a dictionary e.g. data[userDefinedName].
>
> Only if you use assignment into an object that delegates to
> Object.prototype, but see (1) above: this hazard already exists. Don't
> do that; JSON doesn't, and Object.create(null) gives a way to create
> dictionaries.
>
> Yes, the problems you cite are real, but they are already part of the
> de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
> mistake due to (2).
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss  
>   
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is steps are very thing


Tom Schuster wrote:

I like to disagree. I was quite familiar with the ES spec about a year
ago and this still confused me. Only because this is pre-existing
doesn't make the language very clear.


I agree it's a bit awkward learning to read every Clause 15 method spec 
in terms of the Clause 15 intro's subtle language about missing 
arguments. Kind of a pain, really. But in the interest of a minimal 
spec, to avoid redundancy that can then mutate and diverge, making spec 
bugs, we generally try to hoist such common "code", if you will.


Do you think a specific change should be made for Object.is, or for all 
method specs in 15?


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mutable Proto