Axel Rauschmayer wrote:
But maybe it’s the best we can do.
There is no total class hierarchy describing all values in JS. If you
think we should retrofit one, make that case.
There is a subclass relationship between types in JavaScript.
instanceof is aware of it, typeof isn’t. So I think
So I think my complaint is better phrased like this: Why do people have to
be aware of the difference between primitives and objects when it comes to
choosing between typeof and instanceof?
This is a question about JS today? Obviously (as discussed on twitter) people
have to be aware.
Axel Rauschmayer wrote:
Makes sense. Maybe the syntax/API for setting up operators can be
designed in a way that keeps the option open of adding complete
multiple dispatch later (or via a library).
Function.defineOperator has a rationale (convenience, boilerplate
reduction) even in a world
Axel Rauschmayer wrote:
Again, are you suggesting a retrofit along the lines I diagrammed, so
that (hi instanceof string) would be true?
I don’t have a definite answer for how to best fix this, but it would
be lovely if we could.
Would it? Having string as well as String might be useful at
languages that use imperative iterators, like Python and PHP.
And JS -- JS has mutation and objects. It's not going to swerve
toward Haskell (sorry, Claus).
I never understood your automated dislike of Haskell.
You misread me pretty badly here. Why?
Your dislike of Haskell as a
The defining feature of symbols is that they are unguessable, but this
feature is useless in the context of unique symbols, since one can always
just get to the symbol by property inspection. As such, symbols appear to
provide no benefit over strings for this use case.
In fact, unique strings
# July 25 Meeting Notes
John Neumann (JN), Luke Hoban (LH), Rick Hudson (RH), Allen Wirfs-Brock
(AWB), Yehuda Katz (YK), Anne van Kesteren (AVK), Jeff Morrison (JM),
Sebastian Markbage (SM), Alex Russell (AR), Istvan Sebestyen (IS), Mark
Miller (MM), Norbert Lindenberg (NL), Erik Arvidsson (EA),
On Sun, Jul 28, 2013 at 5:09 PM, Axel Rauschmayer a...@rauschma.de wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
When you import a module programmatically, you have an error callback:
Loader.prototype.import( name, callback, errback, referer = null )
How do you
On Jul 29, 2013, at 5:26 AM, Kevin Smith zenpars...@gmail.com wrote:
The defining feature of symbols is that they are unguessable, but this
feature is useless in the context of unique symbols, since one can always
just get to the symbol by property inspection. As such, symbols appear to
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
BE: Why can't we just have (private) Symbols
BE: Can we unwind the split between private and unique?
These struck a chord with me. Thus, in the spirit of
BE: We aren't going
Hi,
Originally, direct proxies were specified such that a direct proxy would
inherit the [[Class]] of the target object it wraps. The intent was for
e.g. proxies-for-arrays to be recognized properly as arrays.
In ES6 the [[Class]] property is gone and the current draft instead uses
wording such
{ [stringSym]: value }
// or
obj[stringSym] = value
leaks to Object.keys and for-in, which are very commonly used operations
and will get used in conjunction with getting and setting. That destroys
the encapsulation component of Symbols, which I argue is one of (if not the
reasons I've suggested a getter is the affinity with DOM indeed while for
the Object redefinition part looks basically what I've simulated here:
https://github.com/WebReflection/another-js#anotherjs-api
able to use emulated reflection too. Didn't know about Allen proposal, cool
stuff!
On Sun,
Domenic Denicola wrote:
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
BE: Why can't we just have (private) Symbols
BE: Can we unwind the split between private and unique?
These struck a chord with me. Thus, in the
Claus Reinke wrote:
languages that use imperative iterators, like Python and PHP.
And JS -- JS has mutation and objects. It's not going to swerve
toward Haskell (sorry, Claus).
I never understood your automated dislike of Haskell.
You misread me pretty badly here. Why?
Your dislike of
On 7/29/2013 10:03 AM, Kevin Smith wrote:
Are you arguing that non-enumerability is a useful encapsulation
mechanism?
I believe enumerability has a propensity to get in the way of encapsulation.
The main use case that I've seen for for-in and Object.keys is using a
plain object as a map.
Brandon Benvie wrote:
On 7/29/2013 10:03 AM, Kevin Smith wrote:
Are you arguing that non-enumerability is a useful encapsulation
mechanism?
I believe enumerability has a propensity to get in the way of
encapsulation.
Yes, because (among others) for-in loops that don't expect some
2013/7/29 Brandon Benvie bben...@mozilla.com
My experience is that inheritance is usually done shallowly and these
collisions are rare and obvious when they happen.
It is not obvious when using mixins in UI code. Method names like
_onWindowResize are common and can easily lead to conflicts.
It is safer to use a Map but it is not more convenient. I expect to
continue seeing people using object literals and mixing properties for
things like option objects for a long time to come.
Sure, but with objects-as-maps, you're not interested in encapsulating
the keys. It's moot.
On Jul 29, 2013, at 9:06 AM, Tom Van Cutsem wrote:
Hi,
Originally, direct proxies were specified such that a direct proxy would
inherit the [[Class]] of the target object it wraps. The intent was for e.g.
proxies-for-arrays to be recognized properly as arrays.
In ES6 the [[Class]]
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
+1. I've been wondering this for a long time but thought that there was too
much consensus around unique symbols to question it. I'm glad these questions
are being asked. I
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design protocols
without having to globally coordinate on property or method names.
(E.g. iterator)
I think {keys, maps, values} (and the pivot to using Symbols and
functions for them)
Brandon Benvie wrote:
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design
protocols without having to globally coordinate on property or method
names. (E.g. iterator)
I think {keys, maps, values} (and the pivot to using Symbols and
On 7/29/2013 1:09 PM, Brendan Eich wrote:
Brandon Benvie wrote:
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design
protocols without having to globally coordinate on property or
method names. (E.g. iterator)
I think {keys, maps, values}
Brandon Benvie wrote:
On 7/29/2013 1:09 PM, Brendan Eich wrote:
Brandon Benvie wrote:
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design
protocols without having to globally coordinate on property or
method names. (E.g. iterator)
I think
On 7/29/2013 1:29 PM, Brendan Eich wrote:
More recently, Jason implemented 'iterator' for two reasons, I think:
1, lack of symbol spec of implementation as prerequisite; 2, belief
that a public name was better. Jason argued that case here, but I
don't think he prevailed (Dean Landolt
I am not sure I completely understand what a realm is but I am assuming it
is similar to a set of primodials (say an iframe in a browser).
Unless I am really misreading your examples, I do not think the new
proposal overcomes the problems of http://wiki.ecmascript.org/**
๏̯͡๏ Jasvir Nagra wrote:
I am not sure I completely understand what a realm is but I am
assuming it is similar to a set of primodials (say an iframe in a
browser).
Hi Jasvir,
Tes: realm is the primordials (memoized internally at start of world;
older ECMA-262 specs wrote of the original
Various thoughts...
Slipping in support for redefining 'typeof null' feels like the sort of thing I
sometimes try to squeeze through ;-)
Why is setTypeOf attached to Function? There would seem to be very little to
naturally associate it with Function. I suppose it's because that's where you
From: Allen Wirfs-Brock [al...@wirfs-brock.com]
Why is setTypeOf attached to Function? There would seem to be very little to
naturally associate it with Function. I suppose it's because that's where
you put 'defineOperator'. Even there, the association with Function seems
tenuous. I
On Mon, Jul 29, 2013 at 4:29 PM, Brendan Eich bren...@mozilla.com wrote:
Brandon Benvie wrote:
On 7/29/2013 1:09 PM, Brendan Eich wrote:
Brandon Benvie wrote:
On 7/29/2013 11:33 AM, Kevin Smith wrote:
The value of uniqueness lies in the fact that you can design protocols
without having
Allen Wirfs-Brock wrote:
Various thoughts...
Thanks, it's pre-strawman here so all are welcome.
Slipping in support for redefining 'typeof null' feels like the sort of thing I
sometimes try to squeeze through ;-)
Heh. It's one reason for Function as the static namespace (no methods on
Domenic Denicola wrote:
From: Allen Wirfs-Brock [al...@wirfs-brock.com]
Why is setTypeOf attached to Function? There would seem to be very little to
naturally associate it with Function. I suppose it's because that's where you put
'defineOperator'. Even there, the association with
Dean Landolt wrote:
FWIW Jason convinced me in the end -- I was subtly misinterpreting the
spec.
Oh, my apologies!
Allen, what say you? We should resolve this ASAP since engines are
implementing ES6 for-of and iterators. Cc'ing Andy too.
I still believe symbols (or something like them) are
On 7/29/2013 4:04 PM, Brendan Eich wrote:
Regarding realm associations? What is the rationale for making the
typeof binding per realm? I would expect the people would want (at
least operator associated) value object instances to be freely used
across realms, just like numbers, strings, and
Brandon Benvie wrote:
For value objects, I think it would be problematic if `1m +
iframeEval('1m')` or `1m === iframeEval('1m')` didn't work. It would
also be a shame if my user-overloaded `new Point(0, 0) +
iframeEval('[5, 5]')` didn't work.
Really? How often does cross-frame application
Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit :
The legacy [[Class]] internal property conflated these two concepts. Sometimes
it was used for to ensure that a built-in method was operating upon an instance
that actually had the internal state or conformed to other implementation level
David Bruant wrote:
Also, I fail to understand the difference between if O is an exotic X
object and if O.[[Class]] === X.
+1
What have we gained?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 7/29/2013 4:47 PM, Brendan Eich wrote:
Brandon Benvie wrote:
For value objects, I think it would be problematic if `1m +
iframeEval('1m')` or `1m === iframeEval('1m')` didn't work. It would
also be a shame if my user-overloaded `new Point(0, 0) +
iframeEval('[5, 5]')` didn't work.
Honing in on disagreement (rest is ok).
Brandon Benvie wrote:
I don't see an issue with using a string to identify a builtin type
for user operator overloading though, since you don't end up with
multiple copies of the same user type. If my application (which uses
multiple realms, like say
On Mon, Jul 29, 2013 at 5:20 PM, Brendan Eich bren...@mozilla.com wrote:
Brandon Benvie wrote:
. An Array would be identified the same way as it is currently in the ES6
spec: any object that is an Exotic Array Object would match 'Array'; for
map, any object that has [[MapData]] matches 'Map',
On 7/29/2013 5:20 PM, Brendan Eich wrote:
Honing in on disagreement (rest is ok).
Brandon Benvie wrote:
I don't see an issue with using a string to identify a builtin type
for user operator overloading though, since you don't end up with
multiple copies of the same user type. If my
On 7/29/2013 5:14 PM, Brendan Eich wrote:
David Bruant wrote:
Also, I fail to understand the difference between if O is an exotic
X object and if O.[[Class]] === X.
+1
What have we gained?
It seems to me like duck-typing based on internal properties was
basically superseded by @@create
On Jul 29, 2013, at 5:11 PM, David Bruant wrote:
Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit :
The legacy [[Class]] internal property conflated these two concepts.
Sometimes it was used for to ensure that a built-in method was operating
upon an instance that actually had the internal
Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit :
On Jul 29, 2013, at 5:11 PM, David Bruant wrote:
Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit :
The legacy [[Class]] internal property conflated these two concepts. Sometimes
it was used for to ensure that a built-in method was operating
Brandon Benvie wrote:
On 7/29/2013 5:20 PM, Brendan Eich wrote:
Honing in on disagreement (rest is ok).
Brandon Benvie wrote:
I don't see an issue with using a string to identify a builtin type
for user operator overloading though, since you don't end up with
multiple copies of the same user
46 matches
Mail list logo
