a principle or rule established in a previous case:
http://en.wikipedia.org/wiki/Precedent
I should not be here and I will not answer, just my last attempt trying to
make a point.
Please consider the main developer behind node.js agrees this property
should never land in JS as it's a minefield
On 12 April 2013 09:01, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
// all Mobile WebKit browsers
*if* ('__proto__' *in* Object.create(*null*)) {
console.log('you gonna have hard time');
}
If this is true that means it breaks the *only *way of creating a secure
lookup table.
Hey Andrea,
Response inline.
On Fri, Apr 12, 2013 at 9:01 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
a principle or rule established in a previous case:
http://en.wikipedia.org/wiki/Precedent
I should not be here and I will not answer, just my last attempt trying to
make a
It improved a bit, I've just added a new bug and the loading time was
only one minute instead of two minutes.
- André
On 4/12/2013 3:21 AM, Brendan Eich wrote:
I heard some db cleaning was just done -- any improvements?
/be
André Bargull wrote:
A bit off topic:
bugs.ecmascript.org is
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon ro...@w3.org wrote:
On 09/04/2013 16:51 , Brendan Eich wrote:
First, this cuts both ways. Do you really want to get into the times
even in the modern era, even in the last three years, when a W3C/WHATWG
(the two are diverging again) piece of
On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell slightly...@google.comwrote:
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon ro...@w3.org wrote:
On 09/04/2013 16:51 , Brendan Eich wrote:
First, this cuts both ways. Do you really want to get into the times
even in the modern era, even in the
On Friday, April 12, 2013, Rick Waldron wrote:
On Fri, Apr 12, 2013 at 8:10 AM, Alex Russell
slightly...@google.comjavascript:_e({}, 'cvml', 'slightly...@google.com');
wrote:
On Thu, Apr 11, 2013 at 1:51 PM, Robin Berjon
ro...@w3.orgjavascript:_e({}, 'cvml', 'ro...@w3.org');
wrote:
On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote:
The DOM side should all be subscribed to es-discuss and read it on a
regular basis. Additionally, our f2f meeting notes are a great way for them
to keep up to date, as well as providing a good jump off for questions and
On Apr 12, 2013 11:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com
wrote:
The DOM side should all be subscribed to es-discuss and read it on a
regular basis. Additionally, our f2f meeting notes are a great way for
them
On Fri, Apr 12, 2013 at 4:15 PM, Brendan Eich bren...@secure.meer.net wrote:
We need a few people who can drink from a firehose on all the lists, who
then bubble issues up to public-script-coord.
I wish I could. The problem is 1) there's many drafts
http://www.w3.org/TR/#tr_Javascript_APIs (not
The DOM side should all be subscribed to es-discuss and read it on a
regular basis. Additionally, our f2f meeting notes are a great way for them
to keep up to date, as well as providing a good jump off for questions and
concerns.
Given the number of people working on platform APIs that should
Alex, I wrote that with best intents. I have the incredible ability to
transform any thread in a flame so for this mailing list sake is better, as
I've written already, to be as far away as possible (I keep watching
threads though).
I'll try to quickly answer:
@gaz, yes, dictionaries and lookup
Hi Anne, while I mostly agree with Rick, I also see the scalability problem
you're worried about here. Part of the problem is that so many w3c platform
APIs are designed without any appreciation of JavaScript esthetics, often
it seems without any real JavaScript experience, and with WebIDL as the
I'm really happy to see this thread. The past attempts to establish better
communications and coordination between the W3C and Ecma/TC39 have had only
limited success. I think one cause has been a lack of understanding of goals,
plans, progress, and processes among the general population of
André Bargull wrote:
It improved a bit, I've just added a new bug and the loading time was
only one minute instead of two minutes.
That's terrible -- Mozilla IT (bugzilla.mozilla.org) bug filed.
/be
- André
On 4/12/2013 3:21 AM, Brendan Eich wrote:
I heard some db cleaning was just done
Andrea Giammarchi wrote:
Alex, I wrote that with best intents. I have the incredible ability to
transform any thread in a flame so for this mailing list sake is
better, as I've written already, to be as far away as possible (I keep
watching threads though).
At least read up on the topic. A
Brendan Eich wrote:
AFAIK, Chromium might solve this soon so no need to fork it?
http://code.google.com/p/v8/source/detail?r=14139
No, because the setter will be poisoned, per
... https://mail.mozilla.org/pipermail/es-discuss/2013-February/028631.html
It looks like the setter throws only
Adding Object.setPrototypeOf does not help, because code won't migrate to it
completely so we'll be stuck with two APIs.
As shown in the first post we'll be stuck with 4 APIs plus the 5th one
standardized.
The __proto__ that is not supported, the one that is wrongly inherited
in
Based on recent discussions, it seems that there's some confusion about
what exactly Symbols are. So far I've seen three different alternatives:
1.) Exotic objects that conform to the most recent ES6 spec, but with a
special typeof .That is, they have special operations for all the
internal
On 4/13/13 12:12 AM, Brandon Benvie wrote:
Based on recent discussions, it seems that there's some confusion
about what exactly Symbols are. So far I've seen three different
alternatives:
1.) Exotic objects that conform to the most recent ES6 spec, but with
a special typeof .That is, they
On Apr 12, 2013, at 3:12 PM, Brandon Benvie wrote:
Based on recent discussions, it seems that there's some confusion about what
exactly Symbols are. So far I've seen three different alternatives:
1.) Exotic objects that conform to the most recent ES6 spec, but with a
special typeof .That
How would object value types such as int64 work? Should symbols be similar?
On Apr 13, 2013, at 0:35 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 12, 2013, at 3:12 PM, Brandon Benvie wrote:
Based on recent discussions, it seems that there's some confusion about what
exactly
Andrea Giammarchi wrote:
Adding Object.setPrototypeOf does not help, because code won't migrate to it
completely so we'll be stuck with two APIs.
As shown in the first post we'll be stuck with 4 APIs plus the 5th one
standardized.
What 4 APIs are you talking about?
The __proto__ that is
Axel Rauschmayer wrote:
How would object value types such as int64 work? Should symbols be
similar?
That came up and was an argument for making typeof sym == symbol,
given sym = Symbol(). Same for int64 and uint64 in my patch at
https://bugzilla.mozilla.org/show_bug.cgi?id=749786
(Note on
On Apr 13, 2013, at 1:09 , Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
How would object value types such as int64 work? Should symbols be similar?
That came up and was an argument for making typeof sym == symbol, given sym
= Symbol(). Same for int64 and uint64 in my
if you consider Object.setPrototypeOf an API and __proto__ another one then
I consider all variants of __proto__ other APIs
As you said we cannot get rid of so standardizing an extra one on top will
create 5 different scenarios.
Old __proto__ will go away, same could be for __proto__ if ES6 will
Andrea Giammarchi wrote:
if you consider Object.setPrototypeOf an API and __proto__ another one
then I consider all variants of __proto__ other APIs
As *I* just wrote, this counting old pre-ES6 __proto__ variations is
unfair because ES6 can't affect browsers in the field. Knock it off.
As
Axel Rauschmayer wrote:
On Apr 13, 2013, at 1:09 , Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
How would object value types such as int64 work? Should symbols be
similar?
That came up and was an argument for making typeof sym == symbol,
given
he doesn't need to fork V8, he simply needs to
delete Object.prototype.__proto__;
at startup time so I am getting real
On Fri, Apr 12, 2013 at 6:21 PM, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
if you consider Object.setPrototypeOf an API and __proto__ another one
Andrea Giammarchi wrote:
he doesn't need to fork V8, he simply needs to
delete Object.prototype.__proto__;
I double-dog dare anyone to do this and keep all the NPM modules working.
There won't be a standard Object.setPrototypeOf.
Maybe it's time to stop the same runaround as last month, at
also, too much power because of a function instead of a hot/swap through a
property ?
who told you nobody wants that function because prefer __proto__ instead ?
Do you read internet where every developer calls __proto__ ugly ?
And btw, which part I did not reply ... I have no idea, honestly!
On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com
wrote:
The DOM side should all be subscribed to es-discuss and read it on a
regular basis. Additionally, our f2f meeting notes are a great way for
cc es-discuss.
On Fri, Apr 12, 2013 at 10:37 PM, Dirk Pranke dpra...@chromium.org wrote:
One takeaway I have from both my own recent efforts to understand the
state of ES6 and the recent threads on es-discuss and public-script-coord
is that I think someone should be doing a better job of
On Fri, Apr 12, 2013 at 10:17 PM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com
wrote:
The DOM side should all be subscribed to es-discuss and read it on
34 matches
Mail list logo
