In the ECMA 5 RC spec I noticed that 15.4.4.14 Array.prototype.indexOf
(and lastIndexOf) make use of the SameValue operation.
The spec states that (9.12) SameValue will return true If Type(x) is
Undefined or Null.
Would this not cause an issue with 9c of the Array.prototype.indexOf spec.
c. If
I just wanted to point out http://trac.webkit.org/changeset/42478.
The changeset states: This change adds the displayName property to
functions, which when set overrides the
normal name when appearing in the console.
- John-David Dalton
___
es-discuss
something ?
- John-David Dalton
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I think that under 15.4.4.4 Array.prototype.concat
5 - b. - iii - 3 - a. Call ToString(n). could be removed as it
is performed in c.
- John-David Dalton
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
The __proto__ property has been around for ~13yrs and is now a de
facto standard supported by Chrome, Firefox, Safari, Opera, Adobe
Flash, Adobe AIR, Rhino, Ringo, Narwhal, Node.js.
It's available on desktops, mobile phones, tablets, and even eReaders.
The __proto__ property is a powerful
@Oliver
That said your examples environments that support it is slightly misleading
as there's only a few JS engines being used between them: Caraken
(Opera person is this correct?), JavaScriptCore, SpiderMonkey and V8. AIR
uses webkit so pulls in JSC, and presumably ActionScript as well,
For symmetry with
Object.create, you might want Boolean.create, Date.create and so
forth, but that's still initialization-time, and TBH I would be
surprised if there were actually many collisions between libraries
that augment those prototypes.
In the Script Junkie article I cover a few
Array create seems like a good interface for that particular use case even if
the general solution that
encompasses things other than Array ended up being something different.
Limiting it to Array.create seems shortsighted. It's useful for
Strings, Numbers, RegExp, and others.
Adding
There is a general problem of supporting creation of special behavior
objects
Yes, I think it would be ok to assume that the spirit of __proto__ can
be achieved by a solution that sets the [[Prototype]] at creation.
This would possibly help with WebKit's security concerns while not
I think Oliver's original formulation is more correct, but regardless this
really would have to be specified using ES5 pseudo code.
This is along the path of what I was calling a generalized solution to the
problem and as such I think it needs deeper/longer
consideration to be sure we have
Did I miss new, mutating uses of __proto__ in PrototypeJS?
Nope, nothing new in PrototypeJS.
Mutating use of __proto__ can be found in
https://github.com/jdalton/fusejs as 1 of the 3 techniques used.
The __proto__ fork is only being used by Safari (because of a loong
time iframe bug
I think I understand what you doing here, especially for Array but I don't
think it really addresses my Number, Boolean, String question.
Instances of those instances usually aren't created via explicit constructor
calls but by implicit conversions that the ES5 spec. hardwires
to the
But AIUI the point of sandboxing is to keep different libraries from
stepping on each other's toes, and AFAICT such libraries use literals
(string, array, object and regexp) quite liberally.
Sandbox natives are used so FuseJS plays well with others while allowing the
extension/modification of
It was a compatibility nightmare when people didn't namespace, and
when you couldn't make non-enumerable properties. Using a namespace
for additions to the prototype chain and using ES5's defineProperty to
keep those additions from affecting enumeration behaviour seems like
it overcomes
But to get back to shaver's point: you are requiring a stylized, non-standard,
popular-library-incompatible dialect of JS to be used from the start to work
inside FuseJS's sandboxes, IIUC. Right?
Mike was getting OT onto the specifics and merits of sandboxed natives/FuseJS.
I was originally
I dig Array.from, and have manually made sugar for that in my projects.
Array.of is something I have also wanted though I had been struggling
with a name for it.
Until now if I wanted to avoid setting the array length I would do
something like ns.Array.from([23]), but Array.of is nice too ;)
-
Just a heads-up that the tag values for [[IsRegExp]] and [[IsError]],
in Table 23 - Tags for classified native objects, are not correct.
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
- JDD
___
es-discuss mailing list
@Jeff In reply to
https://mail.mozilla.org/pipermail/es-discuss/2011-July/016124.html,
which engines have problems with `firstArray.push.apply(firstArray,
secondArray)` ?
Shouldn't a bug report be filed for the specific JS engine or the spec
be clarified on the subject (String.fromCharCode too)
On Mon, Aug 15, 2011 at 8:42 PM, es-discuss-requ...@mozilla.org wrote:
Send es-discuss mailing list submissions to
es-discuss@mozilla.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with
Sorry about the last empty reply, GMail got ahead of itself :D
So Chrome and Firefox disagree on their Function#bind implementation.
http://es5.github.com/#x15.3.4.5.2
http://es5.github.com/#x15.3.4.5.3
~~~ js
function Bar() {
return 1;
}
var bound = Bar.bind({});
new bound instanceof bound;
Thanks Luke,
Your explanation made it click.
I was going to file a bug report, but found it already existed (from
2010 k).
http://code.google.com/p/v8/issues/detail?id=793
-JDD
On Tue, Aug 16, 2011 at 12:12 PM, Luke Hoban lu...@microsoft.com wrote:
My interpretation of these spec sections:
So @kitcambridge and I were talking spec and started trying to find in
spec something that explains why something like:
Array.prototype.reduce which is by default { [[Writable]]: true,
[[Enumerable]]: false, [[Configurable]]: true } will change to
[[Enumerable]]: true when:
Hiya,
Array.prototype.reduce which is by default { [[Writable]]: true,
[[Enumerable]]: false, [[Configurable]]: true } will change to
[[Enumerable]]: true when:
Array.prototype.reduce = function() {…};
Why do you think this should change [[Enmerable]] to true??
Oh, I *didn't say* I think
Awesome! That was our conclusion too. It was late Kit and I missed
trying it in other implementations (instead we dug into spec because
we thought it was odd). It turns out V8 (Chrome, Node.js) has a bug
that will make non-enumerable properties enumerable by assigning a new
value as in my
So I have read the section (and the notes associated with it) over
what a direct call to eval is:
http://es5.github.com/#x15.1.2.1.1
http://dev.w3.org/html5/spec/Overview.html#script-s-global-object
A direct call to the eval function is one that is expressed as a
CallExpression that meets the
@Oliver Hunt
I have a vague recollection that *monkey treats global object.eval(..) as
a direct eval?
Firefox 4 will execute `window.eval(….)` as in the global execution
context but will still allow access to variables that are accessible
from the execution context of where `window.eval` was
It is a standard (de-facto), we were just talking about making a
non-mandatory normative spec for it. That does carry some weight but
not much more than the de-facto standard, IMHO.
A non-mandatory normative spec, like that of String#substr (even
though JScript implementation is diff) would
From: Andrew Dupont mozi...@andrewdupont.net
JJB has it mostly right. When Sam wrote Object.extend (which was originally
Object.prototype.extend), it didn't use hasOwnProperty; my guess is that Sam
didn't know about it, because most of us were JavaScript amateurs back in the
day, including
On Fri, Oct 7, 2011 at 10:17 AM, Jake Verbaten rayn...@gmail.com wrote:
Object.extend is the only method I shim on every es5 project, so +1
However arguments like library X is would break are stupid, remember es6 is
an opt-in so backwards compat with existing code be damned.
No U! My concern
The cross-browser differences of {}.hasOwnProperty('__proto__') and
{}.__proto__.hasOwnProperty('__proto__') are interesting and need to
be ironed out.
As for the issue of using objects as dictionaries you can simply
prefix keys with some unique value, `var uid = 'uid' + (+new Date);`,
and then
In GWT, we did exactly this prefix operation, and we found GC became a
problem on IE because of it, as each lookup or store in the map creates a
new garbage string.
GWT has larger problems if key prefixes are giving it perf grief (even
in older IE).
- JDD
Actually, there's no reason for the prefix or suffix to be random or
unguessable or
Right, I recently tweeted an example using a zero-width non-breaking
space and at the time suggested it could be something as simple as
using an underscore.
So I was digging through repairES5.js
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#1427
and noticed that:
var a = Object.freeze({ 'x': 1 });
var b = Object.create(a);
b.x = 2;
b.x; // should still be 1
Then I dug into spec and noticed:
Just a bit of back story on Function#bind because I think it's good to know.
Prototype's Function#bind was based on the 2004 post Object-Oriented
Event Listening through Partial Application in JavaScript by Daniel
Brockman:
I noticed in the ES6 draft it states that host objects *do not* have
the [[NativeBrand]] internal property.
I think do not have should be reworded to are not required to have.
This would allow existing inferences like
`{}.toString.call(window.opera) == '[object Opera]'`.
- JDD
@MarkM
Is there something magical about the behavior of this object itself?
For kicks the magical bit would be its awesome pre ES6 internal
[[Class]] value.
Can we leave magical out of a spec convo?
Note that just because the object itself is non-standard and provided by the
host does not
@Allen
I probably need to be more explicit about host objects and add another step
just before step 5
If O is a host object, let tag be an implementation defined string value.
The value may not be Array, Boolean, Date, Error, Function,
JSON, Math, Number, Object, RegExp, and String.
+1
@Allen
We want to be able to define things that were historically implemented as
host objects using pure ECMAScript code. One things such objects have done
is to extend the range of values produced by Object.prototype.toString. So,
we need a pure ECMAScript way to accomplish that.
You
@Allen
and name the internal property [[Class]]. But then, how would you
implement it in pure ES code?
You can name the internal property whatever you want [[Class]] /
[[NativeBrand]] / [[Whatevz]]. It's internal so less important to me
what the name is.
I don't think setting
@/be
No, we do not want normative spec language requiring a per-object
private-named property that determines the
Object.prototype.toString.call(x).slice(8,-1) result.
Doing this naively will both impose unacceptable overhead *and* allow
type-confusion attacks.
I'm talking about adding
@/be
This too may be ok if not observable. But you wrote:
You could simplify it by making `NativeArray = Array` and
`NativeRegExp = RegExp` and so on. Then you could drop the Tags
table and extending the range of Object#toString is as easy as adding
a custom [[NativeBrand]] property value.
@MarkM
A host object is an object supplied by the host environment to
complete the execution environment of ECMAScript.
Sigh. This came up last time as well, and as participants in the spec
writing process our only excuse was That text isn't normative. That
doesn't really excuse it from
Can someone confirm/reject that by spec (http://es5.github.com/#x15.4.4.12):
// sparse array ;D
var a=[0];
a[2]=2;
// the resulting arrays length should be 1 and not 2
console.log(a.splice(0, 2).length);
I'm seeing `2` in latest Chrome/FF.
Thanks,
-JDD
Just checked and IE8 returns `[]` correctly w!
On Tue, Jul 3, 2012 at 8:49 AM, John-David Dalton
john.david.dal...@gmail.com wrote:
I recently saw something like
var a = ['a', 'b', 'c', 'd'];
a.splice(2); // - ['c', 'd'] in latest Chrome, Opera, Firefox, Safari,
Rhino, RingoJS, you
I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would
it make sense to instead check that the [[BuiltinBrand]] is
BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also
allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts?
- JDD
Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent the global `isNaN('foo')` confusion. Though
`Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just
an oversight? I know `Object(NaN)` is totally edge case but it still has
the brand of
for `NaN` and `Object(NaN)`
as well.
On Thu, Dec 13, 2012 at 8:36 PM, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It
would still prevent
Honest question: I have yet to see boxed values in practice. Are there
any real use cases?
See Modernizr:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23
-JDD
On Thu, Dec 13, 2012 at 8:26 PM, Axel Rauschmayer a...@rauschma.de wrote:
Honest question: I have
No, the whole point of Number.isNaN is to provide a definitively test
for NaN number values which cannot be tested for in the usual way using
===.
Wat? This seems to be a good reason to allow `Object(NaN)` and use the
NumberWrapper brand as it cannot be tested via the normal way of `myNaN
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
That's my point. Normally testing for NaN can be done via `myNaN !== myNaN`
but `Object(NaN)` throws a wrench in that.
It would be great if there was 1 function that was able to detect NaN,
instead of having libs step up and do it.
-JDD
Eich bren...@mozilla.com wrote:
John-David Dalton wrote:
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
That's my point. Normally testing for NaN can be done via `myNaN !==
myNaN` but `Object(NaN)` throws a wrench in that.
It would be great if there was 1 function that was able
I apologize for the duplicate post, but I think my reply got lost in its
formatting.
The Modernizr example was in response to Axel's request for an example of
boxed values being used in real world projects.
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the
keys of `source` objects. This helps avoid the method gotchas faced by
developers previously with things like `Object.prototype.writable = true`
and `Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
I agree with you that this would be a much better design, but it would
break backwards compatibility with ES5, no?
There have been other changes to the spec that are technically back-compat
breaking like Object.keys('x') no longer throwing an error.
I think this change would benefit developers
Thanks for the discussion links, Allen.
I'm I reading it right that there was no concrete resolution to the issue?
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Is Post-ES6 up for discussion? Should I create a spec bug for tracking this?
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Rock, will do. Thanks!
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have
settled on using Object.prototype.toString.call as a way to determine the
kind of a value and don't expect that to throw.
This is edge case but it seems like an unnecessary gotcha to throw at devs.
- JDD
On Fri, Aug 29, 2014
, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Aug 29, 2014, at 12:10 PM, John-David Dalton wrote:
JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have
settled on using Object.prototype.toString.call as a way to determine the
kind of a value and don't expect that to throw
MooTools breaking because of additions/changes is not a new thing. It has
been broken in the past by things like Function#bind, String#contains,
Moz removing document.getBoxObjectFor.
Its activity has slowed overall though there is an effort to re-energize
core contributions. Their core has put
Just a heads up, I've pinged MooTools core to inquire about fast-pathing a
patch release for Array#contains.
- JDD
On Tue, Sep 30, 2014 at 1:29 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/30/14, 3:45 PM, Andrea
There is no need to change the name.
MooTools has had these issues in the past (they've broke with ES5, ES6,
ES7 methods).
Array#contains is ES7 so there's time for their patch to release/propagate.
- JDD
On Tue, Sep 30, 2014 at 3:04 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On
Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,
I didn't, but will follow up with that.
JDD
On Tue, Sep 30, 2014 at 3:50 PM, Brendan Eich bren...@mozilla.org wrote:
John-David Dalton wrote:
Just a heads up, I've pinged MooTools core
So put ES7 features behind a flag until the water clears a bit. We'll get
there.
It kind of surprises me (a good surprise) that now, because of JSFiddle,
there's super interest in MooTools. When in the past, when MooTools was
arguably more popular, it didn't stop the language and browsers from
A more general solution seems like a good idea.
Renaming doesn't really solve the deeper issue.
Extending native prototypes is a JavaScript thing and something that will
most likely continue continue.
Ember adds methods to Array.prototype and Function.prototype by default:
On Tue, Sep 30, 2014 at 5:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/30/14, 8:12 PM, John-David Dalton wrote:
Extending native prototypes is a JavaScript thing and something that
will most likely continue continue.
Note that if people were extending in nice ways, using defineProperty
-brock.com
wrote:
On Jan 28, 2015, at 4:40 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
Kind of a bummer. The isTypedArray example from
https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-59
is
incorrect. Is there an updated reference somewhere
Kind of a bummer. The isTypedArray example from
https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-59
is
incorrect. Is there an updated reference somewhere?
The toStringTag result is handy because it allows checking against several
tags at once without having to invoke
At the moment that throws too. Anyways it's something to hammer on a bit.
Maybe Jordan can kick it around too.
Thanks,
-JDD
On Wed, Jan 28, 2015 at 5:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jan 28, 2015, at 5:03 PM, John-David Dalton
john.david.dal...@gmail.com wrote
In the wild I've seen ltrim rtrim which are variations of trimLeft and
trimRight and padLeft padRight or lpad, rpad for other forms. For stings I
think of left and right as leading and trailing and think of start and end
as more position indicators of like slice or a range.
-JDD
On Mon, Jul 27,
Hiya,
> [Enumerate]] must obtain the own property keys of the target object as if
by calling its [[OwnPropertyKeys]] internal method
Whoa that's tricky language. I assumed reading it that [[Enumerable]] was
to follow the order of [[OwnPropertyKeys]] (as part of "as if by") and
walking the
71 matches
Mail list logo
