Allen Wirfs-Brock wrote:
On Jan 7, 2013, at 4:09 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
OK, I ready you proposal. I'll summaries it:
class Sub extends Super {
constructor (...args) {
super(...args); //or super.constructor(...args) because they mean the
same thing.
}
}
creates
Kevin Smith wrote:
I think it's arguable either way. I mean, the initializer-only behavior
advocated by Allen et al makes the class useless when called (as opposed
to new'd).
I don't think such an opinionated approach is really necessary. One can
account for the funky behavior of the
On Mon, Jan 7, 2013 at 11:59 PM, Rick Waldron waldron.r...@gmail.com wrote:
The initialVal argument is _optional_ and undefined is valid — how would you
decide if what was passed should be initial value or thisArg?
I see. Well, ship has sailed. Thanks.
- peter
...(Could have specced the
Herby Vojčík wrote:
In a few words, with class and constructor separated, you can specify
what object should represent the class
Why? Where are the use-cases driving this, which goes beyond class as
constructor function that can be called as well as new'ed?
(and is given appropriate
[repost; first version a few days ago disappeared somewhere]
Hello,
recently I came over two issues of the very similar pattern, involving
semantics of new language constructs. In both cases it seems to be that
being bolder about changes that _new_constructs_ bring (that is, not
making too
As I said: 'undefined' and 'not provided' have a complex relationship in
the ES spec. The ship has sailed, but the turd is the shiniest turd you've
ever seen.
On Tuesday, January 8, 2013, Peter van der Zee wrote:
On Mon, Jan 7, 2013 at 11:59 PM, Rick Waldron
waldron.r...@gmail.comjavascript:;
You are describing path dependency, which afflicts us all, in various
evolving systems including JS.
We cannot keep resetting ES6 to include and think through and make
consistent things such as nil. Sorry, that trades off badly against
developers' time -- they need the good stuff coming
Brendan Eich wrote:
Herby Vojčík wrote:
In a few words, with class and constructor separated, you can specify
what object should represent the class
Why? Where are the use-cases driving this, which goes beyond class as
constructor function that can be called as well as new'ed?
This
Herby Vojčík wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
In a few words, with class and constructor separated, you can specify
what object should represent the class
Why? Where are the use-cases driving this, which goes beyond class as
constructor function that can be called as well as
Brendan Eich wrote:
You are describing path dependency, which afflicts us all, in various
evolving systems including JS.
We cannot keep resetting ES6 to include and think through and make
consistent things such as nil. Sorry, that trades off badly against
developers' time -- they need the
Brendan Eich wrote:
Herby Vojčík wrote:
We need to detail how Nil works, how it cannot be wrapped or observed,
etc. in order to maintain equivalence.
In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing,
[[Call]] return Nil. But there are sure some nasty details down there.
Yeah,
Herby Vojčík wrote:
In the light of this I think nil-underneath-resurfaced-as-undefined is
good strategy, things like
(foo=o.p?).q
must be augmentede a bit more:
(foo=o.p?)?.q
Well, I meant this, the previous example is a bit strange:
(foo=o?.p).q
must be
(foo=o?.p)?.q
Herby
On Jan 8, 2013, at 12:45 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
On Jan 7, 2013, at 4:09 PM, Herby Vojčík wrote:
...
I just don't see such an inconsistency in the current ES6 spec. draft. A
constructor is just a function that is usually called with a this value.
This is
Nothing's unfair about designing by use-cases, and that's how a lot of
the Web standards roll.
I'm not sure I'm on topic because I didn't go throug the full thread, only a
few mail, but what about the case of non-constructible DOM objects?
Until recently (still now on IE) you could only
Playing devil’s advocate: Is Dict really necessary? Whenever performance
doesn’t matter (as much), I’d advocate Map. Otherwise, I’d expect programmers
who want the extra speed to be comfortable with Object.create(null).
Assumptions about Dict:
- You still can’t use the key '__proto__'.
- You
To partially answer:
You can use '__proto__' because a dict is basically Object.create(null),
which in ES6 means __proto__ will be just another property. The dict module
also exports entries, keys, and values, so the iteration protocol for a
dict requires using one of those. An example of using
In addition to Brandon's points, it seems to me a clear win from the say what
you mean angle.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Axel Rauschmayer [a...@rauschma.de]
Sent: Tuesday, January 08, 2013 15:13
To:
As to the justification, I would say it's beneficial to use a dict when you
have string keys and you want to be able to use dot property access.
Constantly having to use map.get(key) and map.set(key, value) is overly
verbose if you're using string keys.
On Tue, Jan 8, 2013 at 3:24 PM, Domenic
So, I am playing with FF 18 and I have this behavior:
var a = new Proxy([], {});
console.log(a instanceof Array); // true
console.log(Array.isArray(a)); // true
console.log({}.toString.call(a));// [object Array]
Function.apply(null, a); // anonymous()
Cool uh? there's no way to tell
This is a known problem called Object identity. We already have this problem
today with Object.create(document.createElement(p)) which is an instanceof
HTMLElement but is invalid for any DOM purpose.
However, if you take the same P element and set its __proto__ to null, it will
still be a
On Jan 8, 2013, at 21:24 , Domenic Denicola dome...@domenicdenicola.com wrote:
In addition to Brandon's points, it seems to me a clear win from the say
what you mean angle.
That’s a good point. And __proto__ being just another property helps
tremendously.
However, not having methods seems
More likely, knowing our friendly neighborhood JIT-coders, Maps which only
contain string keys will be optimized under the hood.
From: Axel Rauschmayer [a...@rauschma.de]
Sent: Tuesday, January 08, 2013 16:01
To: Domenic Denicola
Cc: es-discuss list
Subject: Re:
The motivation for the @dict module is also better understood with a bit of
context. Until recently, entries, keys, and values lived in '@iter'. They
work on any object, creating an iterator from its properties. Recently the
three were moved to '@dict' along with @dict.dict being added. In @iter
On Tue, Jan 8, 2013 at 4:01 PM, Axel Rauschmayer a...@rauschma.de wrote:
However, not having methods seems unfortunate. It would be nice for Dicts to
look like Maps with only string keys, but with get(), set() and has() being
optimized under the hood. But maybe that’s too much effort.
It
never even tried that since cloneNode() has been good enough but Proxies
are more powerful than just inheritance so, as it is now, we are trapped
for the DOM while Object.observe(), if I remember correctly, was
reacting/working with DOM too plus makes object somehow proxified or
better observed.
Since proxies always have a target, it would be simple enough for the DOM
internally to use the proxy target. As to whether that's going to happen, I
guess that would be up to implementers.
On Tue, Jan 8, 2013 at 4:15 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
never even tried
On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So, I am playing with FF 18 and I have this behavior:
var a = new Proxy([], {});
console.log(a instanceof Array); // true
console.log(Array.isArray(a)); // true
console.log({}.toString.call(a));// [object
It's certainly possible. I think the point is that we would like to get this
specced instead? Or at least, can we get the TC39-committee do find an
(informative) agreement on the issue if it doesn't fit in a spec?
Date: Tue, 8 Jan 2013 16:18:17 -0500
Subject:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both ... )
On Tue, Jan 8, 2013 at 1:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
On Tue, Jan 8, 2013 at 1:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both ... )
I believe it just wouldn't suffer the same problems - it needs
On Tue, Jan 8, 2013 at 4:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both ... )
Object.observe is different, it works on at [[Get]], [[Put]],
On Tue, Jan 8, 2013 at 4:46 PM, David Bruant bruan...@gmail.com wrote:
One idea would be in the short term that implementations reliably *always*
throw when trying to wrap non-ECMAScript objects and play with them as if
they were legit browser objects. If the need becomes strong,
Right. Even better.
On Jan 8, 2013, at 22:05 , Domenic Denicola dome...@domenicdenicola.com wrote:
More likely, knowing our friendly neighborhood JIT-coders, Maps which only
contain string keys will be optimized under the hood.
From: Axel Rauschmayer [a...@rauschma.de]
Sent: Tuesday,
ooops, that's a typo, the toString is HTMLParagraphElement or the correct
one.
The problem I have here is with identity indeed where this is same as
target in JS world and something else behind the scene in C++ world ...
this is bad because we cannot recognize proxies and we cannot then avoid
We could potentially switch from magic to private symbols but DOM
bindings are highly optimized and I don't think we could afford making
these use symbols. (Right now the pointer is stored at a statically
know offset of the js object.)
Can we use both systems in parallel? In case you hit the
On Jan 7, 2013, at 9:30 PM, Kevin Smith wrote:
I think it's arguable either way. I mean, the initializer-only behavior
advocated by Allen et al makes the class useless when called (as opposed to
new'd).
Not really. If you want to, you can still do the same sort of ad hoc new/call
On Jan 8, 2013, at 1:23 PM, Tab Atkins Jr. wrote:
This is a problem elsewhere, too - Web Components really wants to make
it easy to subclass DOM objects, but we've had to twist ourselves into
knots to do it in a way that alerts the C++ side early enough that
it can create the new objects
François REMY wrote:
In case you hit the invalid cast case, you can check if you
received a Proxy. If you received a proxy, you retry the cast using
its target instead.
For what it's worth, this is exactly how Gecko's WebIDL bindings work.
We use something much like a Proxy to enforce
Allen,
Thanks for the analysis! I think as long as the current design isn't
future-hostile with regard to this @@call hook, we're good. Really,
declarative class-side methods would be a *much* bigger win than providing
support for the call/new split.
{ Kevin }
I was worried that a suffix ? in the pattern language might be
future-hostile to an existential operator or existential member operator,
owing to the fact that suffix ? is grammatically a bit sketchy on the
expression side (in my mind, anyway).
But I think I'm satisfied now. Basically, I don't
On 1/9/13 12:54 AM, Brendan Eich wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy can
be safely cast to its target. The internal proxies Gecko uses are
known implementations where this is safe (with a security check).
And the reason it's safe is that when you then get
41 matches
Mail list logo
