On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote:
On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough barraclo...@apple.com
wrote:
Hi Mark,
In the harmony classes proposal,
http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in
understanding the following issue:
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
Ah, I see. It's a fair point, but isn't this already a hazard that the
language faces?
Not with private names.
Suppose I have two objects, extensible instance X with private instance
property 'foo', and extensible object Y upon which
On Jul 7, 2011, at 11:15 PM, Brendan Eich wrote:
Suppose I have two objects, extensible instance X with private instance
property 'foo', and extensible object Y upon which I have defined a property
'foo' using Object.defineProperty, setting writable=false. If a client of Y
tries to extend
2011/7/7 David Herman dher...@mozilla.com
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
Unless they are private name
It seems like we need to make a change to Object.defineProperties, too
(regardless of the other issue). With the current wording, it will not
forward user attributes to the defineProperty trap. The most modular
fix (that seems compatible with your proposal below) probably is to
change the spec of
Likewise, invoking Object.getOwnPropertyDescriptor on a proxy does not
return user attributes. That actually is explicitly noted in the
semantics for [[GetOwnProperty]], but I'm not sure I see the rationale
behind it.
I would prefer a more coherent story with respect to proxies and user
On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
Ah, I see. It's a fair point, but isn't this already a hazard that the
language faces?
Not with private names.
There's also something that was probably discussed
On Fri, Jul 8, 2011 at 6:36 AM, Juan Ignacio Dopazo
dopazo.j...@gmail.comwrote:
On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
Ah, I see. It's a fair point, but isn't this already a hazard that the
language
I'm not sure. I briefly checked the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects and I
think the detailed interaction with proxies still has to be fleshed out.
Sure, I'll be happy to work with you on this.
The proposal does mention: All
Dear all,
we have seen examples of how to define control-structure
abstractions via block-lambdas (and Smalltalk blocks), including
non-local returns out of user-defined loops.
I'd like to provide an example of how to do something like this
with JS, using only the proposed syntactic sugar for
2011/7/8 Andreas Rossberg rossb...@google.com
It seems like we need to make a change to Object.defineProperties, too
(regardless of the other issue). With the current wording, it will not
forward user attributes to the defineProperty trap. The most modular
fix (that seems compatible with your
2011/7/8 Andreas Rossberg rossb...@google.com
Likewise, invoking Object.getOwnPropertyDescriptor on a proxy does not
return user attributes. That actually is explicitly noted in the
semantics for [[GetOwnProperty]], but I'm not sure I see the rationale
behind it.
I would prefer a more
On Jul 8, 2011, at 6:36 AM, Juan Ignacio Dopazo wrote:
On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
Ah, I see. It's a fair point, but isn't this already a hazard that the
language faces?
Not with private
On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote:
My first thought was: why not just statically replace this.x, with private x,
with this[xPrivateName] and forget about accessing private properties of
other objects? That would still leave the problem of closures inside methods,
On Jul 8, 2011, at 7:17 AM, David Herman wrote:
The proposal does mention: All reflective operations that produce a
property name, when reflecting on a private name, produce the name’s .public
property instead of the name itself.
Would the same hold for reflective operations that consume
Sorry, yes. Too early in the morning for me. :)
Indeed, handler traps are exactly the place where the system *produces* names
and hands them to handler traps which consume them, and that's where it must
produce a public key rather than a private name object.
Dave
On Jul 8, 2011, at 8:20 AM,
And just to be clear, I meant produce in the sense of producer/consumer
relationship on the trap functions, not in the generative sense.
Dave
On Jul 8, 2011, at 8:40 AM, David Herman wrote:
Sorry, yes. Too early in the morning for me. :)
Indeed, handler traps are exactly the place where
On Fri, Jul 8, 2011 at 12:15 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote:
My first thought was: why not just statically replace this.x, with private
x, with this[xPrivateName] and forget about accessing private properties
of other
On Jul 8, 2011, at 7:34 AM, Claus Reinke wrote:
Tailcall optimization guarantees that the callbacks will not overflow the
runtime stack, and tailnest flattening keeps the
level of syntactic nesting independent of the chain length.
ES.next has generators and proper tail calls already. I'm
On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:
You are very much right. What are the open issues with privates in classes
then?
The wiki lists some. Here are a few from memory:
* Syntax to use instead of
On Jul 8, 2011, at 10:20 AM, Juan Ignacio Dopazo wrote:
On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:
You are very much right. What are the open issues with privates in classes
then?
The wiki lists some. Here
The current Harmony classes proposal
http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept of
private instance members and syntax for defining them. While it presents a
syntax for accessing them (eg, private(foo).bar accesses the private 'bar'
member of the object that
On 8 July 2011 21:16, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The current versions of the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects simply
exposes a constructor for creating unique values can be be used as property
keys:
Of the several
On Jul 8, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
The current Harmony classes proposal
http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept
of private instance members and syntax for defining them. While it presents
a syntax for accessing them (eg,
On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
One minor suggestion I'd have is to treat names as a proper new
primitive type, i.e. typeof key == name, not object. That way, it
can be defined much more cleanly what a name is, where its use is
legal (as opposed to proper objects), and
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote on the thread using Private name
objects for declarative property definition. :
But whatever the class syntax, and the disposition of private in class and
even classes in ES.next, I agree we should expect private declarative and
expression
On Jul 8, 2011, at 3:49 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote on the thread using Private
name objects for declarative property definition. :
But whatever the class syntax, and the disposition of private in class and
even classes in ES.next, I agree
On Jul 8, 2011, at 3:59 PM, Brendan Eich wrote:
But the stronger reason for function* as mandator
mandatory of course (need new keyboard).
generator syntax introducer came when we considered yield* (yield from in
Python's PEP380): the utility of a zero-iterations basis case for a
I agree wholeheartedly with these. In fact, I'd go further on (2), and say
Anything that can be done declaratively can also be done imperatively, using
ES5 syntax. ES.next will have two syntaxes running on a single runtime,
sharing objects across a shared heap. I think we should ensure that
On Jul 8, 2011, at 4:05 PM, Luke Hoban wrote:
I agree wholeheartedly with these. In fact, I’d go further on (2), and say
“Anything that can be done declaratively can also be done imperatively, using
ES5 syntax”.
The problem here is that some new syntax cannot be faked with old syntax,
On Jul 8, 2011, at 3:24 PM, Brendan Eich wrote:
On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
Point = {
//private members
[__x]: 0,
[ __y]: 0,
[__validate](x,y) { return typeof x == 'number' typeof y =
'number'},
//public members
new(x,y) {
I agree wholeheartedly with these. In fact, I'd go further on (2), and
say Anything that can be done declaratively can also be done
imperatively, using ES5 syntax.
The problem here is that some new syntax cannot be faked with old syntax,
namely function calls, without quoting code in
On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:
I agree wholeheartedly with these. In fact, I’d go further on (2), and
say “Anything that can be done declaratively can also be done
imperatively, using ES5 syntax”.
The problem here is that some new syntax cannot be faked with old
On Jul 8, 2011, at 4:21 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 3:24 PM, Brendan Eich wrote:
Then the shape of the object is not static. Perhaps this is worth the costs
to implementations and other analyzers (static program analysis, human
readers). We should discuss a bit more
On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:
I agree wholeheartedly with these. In fact, I’d go further on (2), and
say “Anything that can be done declaratively can also be done
imperatively, using ES5 syntax”.
The problem here is that some new syntax cannot be faked with old
On Jul 8, 2011, at 3:49 PM, Allen Wirfs-Brock wrote:
2) Anything that can be done declaratively can also be done imperatively.
What's the imperative API for | (which has the syntactic property that it
operators on newborns on the right, and cannot mutate the [[Prototype]] of an
object that
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
function SubArray() {
return SubArray.prototype | [];
}
SubArray.prototype = new Array;
I'm not sure what Array.prototype methods would or
On Jul 8, 2011, at 5:48 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
What's the imperative API for | (which has the syntactic property that it
operators on newborns on the right, and cannot mutate the [[Prototype]] of
an object that was already created and
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote:
On Jul 8, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
The current Harmony classes proposal
http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept
of private instance members and syntax for defining them. While it
On Jul 8, 2011, at 5:53 PM, David Herman wrote:
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
function SubArray() {
return SubArray.prototype | [];
}
SubArray.prototype = new Array;
On Jul 8, 2011, at 5:53 PM, David Herman wrote:
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
yes, it creates a new object that is an array instance ([[Class]]=='Array',
support the length constraints, etc.)
On Jul 8, 2011, at 6:03 PM, Brendan Eich wrote:
On Jul 8, 2011, at 5:48 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
What's the imperative API for | (which has the syntactic property that it
operators on newborns on the right, and cannot mutate the
On Jul 8, 2011, at 6:38 PM, Allen Wirfs-Brock wrote:
And likewise for Function.create and RegExp.create. Boolean, Number, String,
and Date get nothing :-P.
Actually in the | proposal I define it to work with boolean, number, and
string literals on the LHS. Sorta useless but I included
43 matches
Mail list logo
