On 29 July 2012 03:58, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
I really think in a language where we have both [[Put]] and
[[DefineOwnProperty]] semantics that we really need both = and :=
I can buy that, and I'm glad you mention := as it is not just an assignment
On Aug 14, 2012, at 4:20 AM, Andreas Rossberg wrote:
On 29 July 2012 03:58, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
I really think in a language where we have both [[Put]] and
[[DefineOwnProperty]] semantics that we really need both = and :=
I can buy that, and
Allen Wirfs-Brock wrote:
On Aug 14, 2012, at 4:20 AM, Andreas Rossberg wrote:
On 29 July 2012 03:58, Brendan Eichbren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
I really think in a language where we have both [[Put]] and
[[DefineOwnProperty]] semantics that we really need both =
What’s the best material for reading up on the “override mistake”?
This? http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
On Aug 1, 2012, at 21:56 , Mark S. Miller erig...@google.com wrote:
On Tue, Jul 31, 2012 at 9:05 PM, Brendan Eich bren...@mozilla.org wrote:
This
Yup. It's not very much, but since it seems hopeless it's hard to find
time to write the rest.
On Thu, Aug 2, 2012 at 4:02 PM, Axel Rauschmayer a...@rauschma.de wrote:
What’s the best material for reading up on the “override mistake”?
This?
I’m possibly repeating old arguments, but if the “mistake” was fixed in ES6,
you could still get the ES5.1 behavior by introducing a setter that throws an
exception, right?
On Aug 3, 2012, at 1:04 , Mark S. Miller erig...@google.com wrote:
Yup. It's not very much, but since it seems hopeless
yes. Or simply an accessor property without a setter.
On Thu, Aug 2, 2012 at 4:08 PM, Axel Rauschmayer a...@rauschma.de wrote:
I’m possibly repeating old arguments, but if the “mistake” was fixed in ES6,
you could still get the ES5.1 behavior by introducing a setter that throws
an exception,
Le 01/08/2012 00:05, Brendan Eich a écrit :
David Bruant wrote:
From a practical point of view, if 2 implementations differ on one
aspect of the language, it means that there is no content relying on
either of the 2 implementations for that aspect of the language,
whether they follow the spec
David Bruant wrote:
By the way, I recall something I learned from @mathias. In Chrome:
console.log(document.all); // shows an object in the console
console.log(typeof document.all) // undefined
'all' in document // true
console.log(!!document.all) // false
Such a thing cannot be
On Tue, Jul 31, 2012 at 9:05 PM, Brendan Eich bren...@mozilla.org wrote:
This was debated at last week's TC39 meeting. Between the desire to preserve
this symmetry (not paramount, there are many dimensions and symmetries to
consider) and the V8 bug being fixed (and the JSC bug on which the V8
Mark S. Miller wrote:
On Tue, Jul 31, 2012 at 9:05 PM, Brendan Eichbren...@mozilla.org wrote:
This was debated at last week's TC39 meeting. Between the desire to preserve
this symmetry (not paramount, there are many dimensions and symmetries to
consider) and the V8 bug being fixed (and the JSC
For non-legacy code, given classes and triangle, I don't see the
override mistake as much of a pain point. For co-existence of the
override mistake with legacy code, the only reasonable choice we've
come up with is
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/repairES5.js#347,
The following was WRT [[Put]]/[[CanPut]] semantic issues:
On Jul 28, 2012, at 6:02 AM, David Bruant wrote:
Le 28/07/2012 14:37, Herby Vojčík a écrit :
...
:-/ But that is how it is, no?
That's what the spec says, but V8 has implemented something else (and I
haven't seen an intention to
David Bruant wrote:
That's what the spec says, but V8 has implemented something else (and I
haven't seen an intention to change this behavior), so what the spec
says doesn't really matter.
I missed this until Allen's reply called it out. It is both false
(Google people at the TC39 meeting
On Sat, Jul 28, 2012 at 6:02 AM, David Bruant bruan...@gmail.com wrote:
That's what the spec says, but V8 has implemented something else (and I
haven't seen an intention to change this behavior), so what the spec
says doesn't really matter.
We have a fix for V8 (--es5_readonly) but the
I think my message has been taken the wrong way, so I should clarify it:
From a practical point of view, if 2 implementations differ on one
aspect of the language, it means that there is no content relying on
either of the 2 implementations for that aspect of the language, whether
they follow
David Bruant wrote:
From a practical point of view, if 2 implementations differ on one
aspect of the language, it means that there is no content relying on
either of the 2 implementations for that aspect of the language,
whether they follow the spec or even both diverge differently from it.
On Wed, Aug 1, 2012 at 12:05 AM, Brendan Eich bren...@mozilla.org wrote:
(and the JSC bug on which the V8 bug was based already being fixed in iOS6)
Just to nitpick for those following along at home, the bug is fixed in
the just-release *Safari* 6, and @ohunt declined to comment on future
On Jul 28, 2012, at 6:58 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I really think in a language where we have both [[Put]] and
[[DefineOwnProperty]] semantics that we really need both = and :=
I can buy that, and I'm glad you mention := as it is not just an assignment
operator
On Jul 29, 2012, at 6:05 AM, Herby Vojčík wrote:
Brendan Eich wrote:
...
However TC39 favored configurable: true as well as writable: true, to
match JS expectations, in particular that one could reconfigure a data
property (which is what method definition syntax in a class body
Allen Wirfs-Brock wrote:
On Jul 28, 2012, at 6:58 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I really think in a language where we have both [[Put]] and
[[DefineOwnProperty]] semantics that we really need both = and :=
I can buy that, and I'm glad you mention := as it is not just an
Le 28/07/2012 21:04, Allen Wirfs-Brock a écrit :
(...)
We introduce a new operator that is looks like :=
This is the define properties operator. Both the LHS and RHS must
be objects (or ToObject convertible). Its semantics is to
[[DefineOwnProperty]] on the LHS obj a property corresponding
On Jul 30, 2012, at 1:08 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
The problem with Object.extend is that it isn't a single cow path. There
are multiple path leading in the same general direction but taking different
routes. This was the case in 2008 when we considered
Le 28/07/2012 01:55, Rick Waldron a écrit :
Explanation of specification history and roots in newer DOM mutation
mechanism.
AWB: Is this sufficient for implementing DOM mutation event mechanisms?
RWS: Yes, those could be built on top of Object.observe
Probably I must be misreading the
Allen Wirfs-Brock wrote:
The commonly used semantics of ES5's bind did not differ significantly
any other widely used implementation of a Function.prototype.bind
method. so replacing one with the other wasn't disruptive.
Could be, but there were differences:
On Jul 30, 2012, at 2:56 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The commonly used semantics of ES5's bind did not differ significantly any
other widely used implementation of a Function.prototype.bind method. so
replacing one with the other wasn't disruptive.
Could be, but there
Allen Wirfs-Brock wrote:
On Jul 30, 2012, at 2:56 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The commonly used semantics of ES5's bind did not differ
significantly any other widely used implementation of a
Function.prototype.bind method. so replacing one with the other
wasn't
On Mon, Jul 30, 2012 at 2:56 PM, Aymeric Vitte vitteayme...@gmail.com wrote:
Le 28/07/2012 01:55, Rick Waldron a écrit :
Explanation of specification history and roots in newer DOM mutation
mechanism.
AWB: Is this sufficient for implementing DOM mutation event mechanisms?
RWS: Yes, those
Hi,
First and foremost, thanks for the notes :-)
Le 28/07/2012 01:55, Rick Waldron a écrit :
Fix override mistake
# The can put check
(...)
Property in a prototype object that is read-only cannot be shadowed.
Just the same as get-only accessor.
I'd like to add a use case here. Every once
David Bruant wrote:
Hi,
First and foremost, thanks for the notes :-)
Le 28/07/2012 01:55, Rick Waldron a écrit :
Fix override mistake
# The can put check
(...)
Property in a prototype object that is read-only cannot be shadowed.
Just the same as get-only accessor.
I'd like to add a use
Le 28/07/2012 13:43, Herby Vojčík a écrit :
David Bruant wrote:
var a = [];
a.push = function(elem){
if(condition(elem)){
// do something like change the elem value then do an
actual
push
// or throw an error
// or just ignore this
David Bruant wrote:
Le 28/07/2012 13:43, Herby Vojčík a écrit :
David Bruant wrote:
var a = [];
a.push = function(elem){
if(condition(elem)){
// do something like change the elem value then do an
actual
push
// or throw an error
Le 28/07/2012 14:37, Herby Vojčík a écrit :
David Bruant wrote:
Le 28/07/2012 13:43, Herby Vojčík a écrit :
David Bruant wrote:
var a = [];
a.push = function(elem){
if(condition(elem)){
// do something like change the elem value then do an
actual
push
David Bruant wrote:
Le 28/07/2012 14:37, Herby Vojčík a écrit :
David Bruant wrote:
Le 28/07/2012 13:43, Herby Vojčík a écrit :
David Bruant wrote:
var a = [];
a.push = function(elem){
if(condition(elem)){
// do something like change the elem value
It seems like you're indicating that changing a property to a value,
presumably a primitive, is somehow different from setting it to a function.
Regardless of anything else, that's not true even in the way you mean it
because a function can have a thunk that contains state and accomplishes
the
Er also, not almost
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brandon Benvie wrote:
It seems like you're indicating that changing a property to a value,
presumably a primitive, is somehow different from setting it to a
function.
I read Herby as arguing that overriding a prototype property is
low-level, so must use low-level Object.defineProperty. Due
Brandon Benvie wrote:
It seems like you're indicating that changing a property to a value,
presumably a primitive, is somehow different from setting it to a
I never mentioned a primitive, please don't put into my mouth what I did
not say.
function. Regardless of anything else, that's not
Sorry, I had just completely misread what you read saying. My fault!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Jul 28, 2012, at 5:37 AM, Herby Vojčík wrote:
...
To be precise, [[Put]] and [[DefineProperty]] are different intents.
Dveelopers may not like it, because they used to [[Put]], but it is probably
needed to distinguish them.
[[Put]] is high-level contract (a, update your 'push' facet
On Sat, Jul 28, 2012 at 9:04 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
snip
I snipped, but I agree with all of your claims. While evangelizing our
intention to try for a .{} that supported [[Put]] and [[DefineOwnProperty]].
Given something like this...
.{
a: apple,
b = banana
};
# July 25 2012 Meeting Notes
Present: Mark Miller (MM), Brendan Eich (BE), Yehuda Katz (YK), Luke Hoban
(LH), Andreas Rossberg (ARB), Rick Waldron (RW), Alex Russell (AR), Tom
Van-Cutsem (TVC), Bill Ticehurst (BT), Rafeal Weinstein (RWS), Sam
Tobin-Hochstadt (STH), Allen Wirfs-Brock (AWB), Doug
42 matches
Mail list logo
