Axel Rauschmayer wrote:
Can you explain? What is this copying price and why don’t non-strict
functions have to pay it?
Strict functions have an arguments object that does not alias formal
parameters:
js function f(x) { print(x); arguments[0] = 42; return x; }
js f(99)
99
42
js function g(x)
Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
It also made me think that perhaps Object.mixin might be a more
intuitive name for such a function.
This name is certainly more real-word-friendly.
Works well as an arrow function due to not needing to turn it into a block
body, although forEach and a comma would work too.
Object.mixin = (target, source) =
Object.keys(source).reduce((target, key) =
Object.defineProperty(target, key,
Object.getOwnPropertyDescriptor(source, key))
),
It was suggested to me that we could probably extend String.fromCodePoint
to be aware of UTF-16 code units too. It seems doable since the lead
surrogate is not a valid code point.
The question is if it is worth it? It seems like we are going down a
slippery slope if we start to do things like
On Wed, Dec 12, 2012 at 1:59 AM, Axel Rauschmayer a...@rauschma.de wrote:
I would still love to have something like that in ES6 (loosely similar to
String.prototype.repeat). Once you have that, you can e.g. use
Array.prototype.map to do more things.
Two possibilities:
-
For non-strict functions, formal parameters and the argument object can share
the same storage on the processor stack. Strict functions require a copy, if
either a formal or an args object element is modified. The conserative
implementation is to always copy.
AllenBrendan Eich
Allen Wirfs-Brock wrote:
3) I don't see any reason that it should be restricted to enumerable
properties. If the intend is to deprecate enumerable along with for-in
then we should be adding new functionality that is sensitive to the
state of the enumerable attribute.
Allen
Well, I had a
Hilarious, I haven't seen anything similar to Array#unique yet which is
much more common operation ( see the needing of Set ) and you are
suggesting this that in my experience has basically no use cases except for
zero filled flat matrixes ? :-)
function repeat(times) {
var out = [], i =
agreed, and actually one of the best case I've seen in a while for
Array#reduce.
Can I write this as it should be for those who'll read one day later on and
making it also static ?
mixin in Object || Object.defineProperty(Object, mixin, {
value: function mixin(target, source) {
return
Ah yes errors. It should probably have similar semantics to how
defineProperties works now...attempting each property and holding errors
until the end, no? Same for assign.
function mixin(target, source){
if (Type(target) !== 'Object') throw new TypeError (target must be an
object);
if
a single property from a mixin that cannot be defined could compromise
entirely the behavior so I would actually throw instantly then I believe no
try catch is even necessary there, correct?
On Wed, Dec 12, 2012 at 9:42 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
Ah yes errors. It
On Wed, Dec 12, 2012 at 9:42 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
Ah yes errors. It should probably have similar semantics to how
defineProperties works now...attempting each property and holding errors
until the end, no? Same for assign.
No, we want early errors and accurate
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we want this feature to land and not just spin around here.
jjb
As Object.mixin or as Object.define??
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
All the Object functions that operate on multiple properties are currently
specified using *pendingException* which reports the first thrown exception
after going through all the properties. defineProperties, freeze, etc.
___
es-discuss mailing list
Brandon Benvie wrote:
Works well as an arrow function due to not needing to turn it into a
block body, although forEach and a comma would work too.
Object.mixin = (target, source) =
Object.keys(source).reduce((target, key) =
Object.defineProperty(target, key,
On Wed, Dec 12, 2012 at 10:05 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we want this feature to land and not just spin around
here.
jjb
As Object.mixin or as Object.define??
Object.mixin
jjb
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object functions that operate on multiple properties are currently
specified using pendingException which reports the first thrown exception
after going through all the properties. defineProperties, freeze, etc.
In, ES6. This is
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object functions that operate on multiple properties are currently
specified using *pendingException* which reports the first thrown
exception after
Yeah, it makes sense. If a property throws then you're going to end up with
a partially completed action either way (unless the very first one fails in
the ES5 rules), so it's better to fail predictably. While the iteration
order of the keys is defined, in this case it's usually not useful for
In order to know what the end state will be for any given property, you
currently need to know whether every preceding property throws or not. With
the ES6 change, there's no interdependence between properties as to whether
they'll end up being visited or not.
On Wed, Dec 12, 2012 at 1:23 PM,
On Dec 11, 2012, at 10:42 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
3) I don't see any reason that it should be restricted to enumerable
properties. If the intend is to deprecate enumerable along with for-in
then we should be adding new functionality that is sensitive to the
A contrived example but it demonstrates the problem
Object.mixin({}, Proxy({ a: 5, b: 10, c: 20 }, {
getOwnPropertyDescriptor(target, key){
if (key === 'b' Math.random() * .5) {
throw 'halt';
}
return Reflect.getOwnPropertyDescriptor(target, key);
}
}));
In ES5 rules
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object functions that operate on multiple properties are currently
specified using
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object
On Dec 12, 2012, at 10:10 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:05 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we want this feature to land and not just spin around here.
jjb
As
I'd vote for replacing duplicate properties by default (as I tend to see
this as the common case). That being said, the mixin functions I use
tend to have an optional third argument that let's you change that
behavior, such as:
// regular
Object.mixin(receiver,supplier);
// safe
Hi,
A good question by Anne van Kesteren [1] followed by good remarks by
Boris Zbarsky [2][3] made me try a little something [4][5].
The WindowProxy object returned as the 'contentWindow' property of
iframes never changes; whatever you do when changing the @src, always
the same object is
On Dec 12, 2012, at 10:52 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com wrote:
A good question by Anne van Kesteren [1] followed by good remarks by Boris
Zbarsky [2][3] made me try a little something [4][5].
The WindowProxy object returned as the 'contentWindow' property of iframes
never changes;
This can be handled by proxies and in fact it's something I've done with
proxies for App.js for pretty much the same scenario. A single Window
object exists for each desktop window created, but the page can be
navigated as it does in a browser, wiping out the entire context's object
graph. The
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
A good question by Anne van Kesteren [1] followed by good remarks
by Boris Zbarsky [2][3] made me try a little something [4][5].
The
On Wed, Dec 12, 2012 at 11:20 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:52 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12,
Window interceptors (as we call them in the browser world) are simply nuts.
We simply shouldn't be terribly interested in re-creating this wart.
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
With the previous proxy design indeed. I see you're using Proxy.create [1]
But it won't be possible to do this with the new design, because of
invariant enforcement.
I recommend staying away from Proxy.create as it's likely to not appear
in the spec and be removed from implementations.
On Wed, Dec 12, 2012 at 11:39 AM, David Bruant bruan...@gmail.com wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.comwrote:
The WindowProxy object returned as the 'contentWindow' property of
iframes never changes; whatever
Le 12/12/2012 20:44, Alex Russell a écrit :
Window interceptors (as we call them in the browser world) are simply
nuts. We simply shouldn't be terribly interested in re-creating this wart.
I'm not sure I understand your point. Do you mean that emulating them in
pure ECMAScript should be an
Yep.
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:44, Alex Russell a écrit :
Window interceptors (as we call them in the browser world) are simply
nuts. We simply shouldn't be terribly interested in re-creating this wart.
I'm not sure I understand your point. Do
On Dec 12, 2012, at 11:40 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 11:20 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:52 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec
Le 12/12/2012 20:49, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:39 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
bruan...@gmail.com mailto:bruan...@gmail.com wrote:
On Wed, Dec 12, 2012 at 12:03 PM, David Bruant bruan...@gmail.com wrote:
Le 12/12/2012 20:49, Kevin Reid a écrit :
I haven't made it public yet, but it's just the obvious implementation
of an (old-style, as implemented in Firefox/Chrome) proxy with a switchable
“target”.
Interesting. As
Alex Russell wrote:
Window interceptors (as we call them in the browser world) are simply
nuts. We simply shouldn't be terribly interested in re-creating this wart.
Having a stable object identity for the window proxy, while navigating
the window through a series of page loads, requires this
Rick Waldron wrote:
On Wed, Dec 12, 2012 at 1:59 AM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
I would still love to have something like that in ES6 (loosely
similar to String.prototype.repeat). Once you have that, you can
e.g. use Array.prototype.map to
Le 12/12/2012 21:09, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:03 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 20:49, Kevin Reid a écrit :
I haven't made it public yet, but it's just the obvious
implementation of an (old-style, as
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com wrote:
I was a bit too strong in my statement, sorry. Let me rephrase: the
internal [[Target]] can't be changed, but a proxy can emulate changing of
fake target as long as what happens with this fake target doesn't
involve
On Wed, Dec 12, 2012 at 11:57 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
How would throwing early versus throwing late make any different to you?
Because 1) late is a waste, the result is undefined anyway, 2) the exception
thrown is a lie, the operation did not die on the property
This use case is much more strongly aligned with the purely virtual object
than it is for the forwarded one, despite the goal being to wrap real
objects. Doing fancy things with object identity requires it.
On Wed, Dec 12, 2012 at 3:42 PM, Kevin Reid kpr...@google.com wrote:
On Wed, Dec 12,
Le 12/12/2012 21:42, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I was a bit too strong in my statement, sorry. Let me rephrase:
the internal [[Target]] can't be changed, but a proxy can emulate
changing of
I think the latter should replace the previous as overwrite and would not
care much about same property name with only a getter VS only a setter. If
a developer wants both it can use mixin() to define the descriptor.
Back to Nicolas third parameter, true is not as powerful as a
function(target,
Do you know what the people who talked to you mean by aware of UTF-16 code
units?
As specified, String.fromCodePoint, accepts all UTF-16 code units because they
use a subset of the integers allowed as code points (0 to 0x versus 0 to
0x10). For non-surrogate values, you get exactly
On Wed, Dec 12, 2012 at 1:23 PM, David Bruant bruan...@gmail.com wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant (non-configurable property or
preventExtensions)
2. even if its
Le 12/12/2012 22:30, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 1:23 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant
The ability to break invariants of the language either requires an external
object-capability provider to dole out permission to do this (such as what
is currently done with chrome code being executed with access to
privileged internals), or a mechanism in the language to dole out special
On Wed, Dec 12, 2012 at 11:13 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:10 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:05 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we
IMO String.fromCodePoint should disallow U+D800-U+DFFF.
There's already fromCharCode that does that, and a according to The Unicode
Standard, isolated surrogates have no meaning on their own and goes on to
compare them to illegal UTF-8 sequences. IMO CodePoint is a 21 Unicode code
point, and
The spec says for the various Object functions that the properties are
iterated in list order. Doesn't this indicate the order is defined?
On Wed, Dec 12, 2012 at 4:57 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Wed, Dec 12, 2012 at 11:13 AM, Allen Wirfs-Brock
The Unicode standard defines code point as any value in the range of integers
from 0 to 0x10 - see definitions D9 and D10 of chapter 3 [1].
Once you exclude surrogate code points, you have Unicode scalar values
(definition D76), so you're basically proposing a String.fromScalarValue
Brandon Benvie wrote:
The ability to break invariants of the language either requires an
external object-capability provider to dole out permission to do this
(such as what is currently done with chrome code
Just to clarify for anyone following along (including me!), you must
mean Firefox or
Yeah I was using it in the Mozilla terminology way, not referring to the
browser. =D
On Wed, Dec 12, 2012 at 6:16 PM, Brendan Eich bren...@mozilla.org wrote:
Brandon Benvie wrote:
The ability to break invariants of the language either requires an
external object-capability provider to dole
I was looking at D75 of 3.8 Surrogates
My point is that there's no legal scenario for converting basically a UTF-32
input to an isolated surrogate pair. No valid Unicode string could contain
that. So why support it?
-Shawn
-Original Message-
From: Norbert Lindenberg
On Dec 12, 2012, at 2:27 PM, Brandon Benvie wrote:
The spec says for the various Object functions that the properties are
iterated in list order. Doesn't this indicate the order is defined?
Except that the List in question is created containing the names of each
enumerable own property of
István has informed me that the Ecma General Assembly today unanimously
approved ECMA-402, ECMAScript Internationalization API Specification.
http://ecma-international.org/publications/standards/Ecma-402.htm
Norbert
___
es-discuss mailing list
(Resending on behalf of 张立理 otakus...@live.com because his mail
didn't go through.)
According to [section 13 Function
Definition](http://ecma-international.org/ecma-262/5.1/#sec-13) of
ECMAScript-262 5.1, the **Function Declaration** production and the
**Function Expression** production are
On Dec 11, 2012, at 10:19 AM, Andrea Giammarchi wrote:
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use
all ES5 features for mixins too.
I totally agree as well.
Also, the Nicolas example is potentially disaster prone, not in that
specific form, but in the way a
63 matches
Mail list logo
