From a dev standpoint what we need is a clean API to discriminate between
types. Sometimes we want to discriminate between objects (mutable) and
values (immutable), sometimes between functions and non functions,
sometimes between numbers, strings and others, etc. And we don't want to
have to write
Le 05/08/2013 05:54, Brendan Eich a écrit :
David Bruant wrote:
Le 04/08/2013 00:10, Brandon Benvie a écrit :
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to
'Object(x) === x'.
Would type annotations not be a cleaner way of achieving
discrimination between types?
Would these APIs be redundant if we had type annotations?
On Mon, Aug 5, 2013 at 8:13 AM, Bruno Jouhier bjouh...@gmail.com wrote:
From a dev standpoint what we need is a clean API to discriminate between
David Bruant wrote:
Le 05/08/2013 05:54, Brendan Eich a écrit :
David Bruant wrote:
Le 04/08/2013 00:10, Brandon Benvie a écrit :
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to
Le 4 août 2013 à 18:23, Brendan Eich bren...@mozilla.com a écrit :
You must mean by 'objectness' reference-not-value semantics -- typeof
returning object or function and the user ruling out null value (or
opting into null result) doesn't do a thing to reject non-extensible,
Bruno Jouhier wrote:
From a dev standpoint what we need is a clean API to discriminate
between types. Sometimes we want to discriminate between objects
(mutable) and values (immutable), sometimes between functions and non
functions, sometimes between numbers, strings and others, etc. And we
Brian Di Palma wrote:
Would type annotations not be a cleaner way of achieving
discrimination between types?
The topic here was an introspective operator, typeof, or something similar.
Type annotations are a different category and even in static languages,
do not relieve the need for
Claude Pache wrote:
Le 4 août 2013 à 18:23, Brendan Eichbren...@mozilla.com a écrit :
You must mean by 'objectness' reference-not-value semantics -- typeof returning object or
function and the user ruling out null value (or opting into null result) doesn't do a
thing to reject
Le 5 août 2013 à 19:14, Brendan Eich bren...@mozilla.com a écrit :
Claude Pache wrote:
Le 4 août 2013 à 18:23, Brendan Eichbren...@mozilla.com a écrit :
You must mean by 'objectness' reference-not-value semantics -- typeof
returning object or function and the user ruling out null value
Claude Pache wrote:
You're right that people are good at language adaptation, thus it is not
necessary to go as far as to change the nomenclature. The main concern remains,
that they usetoday `Object.isObject` by meaning probably `isReferenceObject`,
so it is prudent not to standardise
Brandon Benvie wrote:
On Aug 3, 2013, at 8:25 PM, Brendan Eichbren...@mozilla.com wrote:
Value objects are non-extensible, no-own-property (so effectively frozen),
compare-by-value objects.
So, importantly, only one of the two existing commonly used tests for 'objectness' will continue to
Brandon Benvie wrote:
On Aug 3, 2013, at 9:03 PM, Brandon Benviebben...@mozilla.com wrote:
On Aug 3, 2013, at 8:25 PM, Brendan Eichbren...@mozilla.com wrote:
Value objects are non-extensible, no-own-property (so effectively frozen),
compare-by-value objects.
So, importantly, only one of
Le 04/08/2013 00:10, Brandon Benvie a écrit :
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to 'Object(x)
=== x'.
On a side note, I think your version of isObject is problematic
David Bruant wrote:
Le 04/08/2013 00:10, Brandon Benvie a écrit :
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to 'Object(x)
=== x'.
On a side note, I think your version of
Le 03/08/2013 02:59, Brendan Eich a écrit :
David Bruant wrote:
Le 30/07/2013 00:12, Brendan Eich a écrit :
๏̯͡๏ Jasvir Nagra wrote:
Unless I am really misreading your examples, I do not think the new
proposal overcomes the problems of
David Bruant wrote:
Ok, good feedback between you and jasvir. This suggests using the
syntax I mooted:
typeof null = null; // lexically rebind typeof null
new code here
typeof null = object; // restore for old code after
I'm not sure I understand how it's different from
Le 03/08/2013 20:44, Brendan Eich a écrit :
David Bruant wrote:
I don't see the benefit of that against a file/function-wise directive.
Lexical means block in the modern Harmony era.
Excellent.
For both null and the new value types, I'm still unclear on why could
devs would choose
Le 3 août 2013 à 12:01, David Bruant bruan...@gmail.com a écrit :
For both null and the new value types, I'm still unclear on why could devs
would choose something different than the default. I feel the incentives can
only weigh in favor of keeping the default. I'm interested in what other
On 8/3/2013 12:30 PM, David Bruant wrote:
That said, I recently worked on a project and I reviewed a pull
request with typeof x === 'object' to ask to replace to 'Object(x)
=== x'.
I was actually the original author of that code. =D The function was:
```js
function isObject(value){
let
Claude Pache wrote:
Fixing `typeof` of old (null) and new value types would be a
solution, but I'm rather definitely considering something like the
defunct `Object.isObject()`. (As a side-note, I suggest `typeof
uint64(0) === number` rather than `=== object` by default.)
That will make for
Brendan Eich wrote:
Claude Pache wrote:
Fixing `typeof` of old (null) and new value types would be a
solution, but I'm rather definitely considering something like the
defunct `Object.isObject()`
I forgot to add that my patch for
https://bugzilla.mozilla.org/show_bug.cgi?id=749786 includes
Le 4 août 2013 à 01:39, Brendan Eich bren...@mozilla.com a écrit :
Brendan Eich wrote:
Claude Pache wrote:
Fixing `typeof` of old (null) and new value types would be a solution, but
I'm rather definitely considering something like the defunct
`Object.isObject()`
I forgot to add that my
Le 4 août 2013 à 01:34, Brendan Eich bren...@mozilla.com a écrit :
Claude Pache wrote:
Fixing `typeof` of old (null) and new value types would be a solution, but
I'm rather definitely considering something like the defunct
`Object.isObject()`. (As a side-note, I suggest `typeof uint64(0)
Claude Pache wrote:
Le 4 août 2013 à 01:39, Brendan Eichbren...@mozilla.com a écrit :
Brendan Eich wrote:
Claude Pache wrote:
Fixing `typeof` of old (null) and new value types would be a solution, but I'm
rather definitely considering something like the defunct `Object.isObject()`
I
Claude Pache wrote:
Le 4 août 2013 à 01:34, Brendan Eichbren...@mozilla.com a écrit :
Claude Pache wrote:
Fixing `typeof` of old (null) and new value types would be a solution, but I'm rather definitely
considering something like the defunct `Object.isObject()`. (As a side-note, I suggest
On Aug 3, 2013, at 8:25 PM, Brendan Eich bren...@mozilla.com wrote:
Value objects are non-extensible, no-own-property (so effectively frozen),
compare-by-value objects.
So, importantly, only one of the two existing commonly used tests for
'objectness' will continue to work correctly in the
On Aug 3, 2013, at 9:03 PM, Brandon Benvie bben...@mozilla.com wrote:
On Aug 3, 2013, at 8:25 PM, Brendan Eich bren...@mozilla.com wrote:
Value objects are non-extensible, no-own-property (so effectively frozen),
compare-by-value objects.
So, importantly, only one of the two
On Fri, Aug 2, 2013 at 1:21 AM, Brendan Eich bren...@mozilla.com wrote:
I thought this was not all that interoperable. What exactly are the
intersection semantics? Not object identity change!
Gecko will change the prototype. WebKit will keep the prototype until
garbage collection has run at
On Aug 1, 2013, at 5:36 PM, Tab Atkins Jr. wrote:
On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich bren...@mozilla.com wrote:
Tab is still looking for a MapLite (tm) that can be customized with hooks.
Obviously to avoid infinite regress, the MapLite bottoms out as native, and
the hooks are on
On Fri, Aug 2, 2013 at 12:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Aug 1, 2013, at 5:36 PM, Tab Atkins Jr. wrote:
On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich bren...@mozilla.com wrote:
Tab is still looking for a MapLite (tm) that can be customized with hooks.
Obviously to
On Aug 2, 2013, at 12:59 PM, Tab Atkins Jr. wrote:
On Fri, Aug 2, 2013 at 12:06 PM, Allen Wirfs-Brock
...
'size' is essentially a primitive of the key/value store.
It can be defined in terms of iterations, but I'm fine with this being
primitive because it's such a small data leak. If
On Aug 2, 2013, at 12:32 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The iterator factory methods of map are all just short-cuts for creating
MapIterator objects which are current specified as friends (in the C++
sense) that know about internal key/value store encapsulated by Map
On Fri, Aug 2, 2013 at 3:34 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 2, 2013, at 12:32 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We can debate whether future new methods should be added to Map or be made
part of distinct new classes.
I think this is the underlying
On Fri, Aug 2, 2013 at 3:02 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Aug 2, 2013, at 12:59 PM, Tab Atkins Jr. wrote:
On Fri, Aug 2, 2013 at 12:06 PM, Allen Wirfs-Brock
...
'size' is essentially a primitive of the key/value store.
It can be defined in terms of iterations, but
David Bruant wrote:
Le 30/07/2013 00:12, Brendan Eich a écrit :
๏̯͡๏ Jasvir Nagra wrote:
Unless I am really misreading your examples, I do not think the new
proposal overcomes the problems of
http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null. If
Function.setTypeOf dynamically
I thought this was not all that interoperable. What exactly are the
intersection semantics? Not object identity change!
/be
Anne van Kesteren wrote:
On Tue, Jul 30, 2013 at 7:15 PM, Brandon Benviebben...@mozilla.com wrote:
I fully admit that this may be overkill to support an edge case, and
Tab is still looking for a MapLite (tm) that can be customized with
hooks. Obviously to avoid infinite regress, the MapLite bottoms out as
native, and the hooks are on the outside (in Map). Tab, do I have this
right?
The even simpler course is to keep Map as spec'ed and make DOM or other
On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich bren...@mozilla.com wrote:
Tab is still looking for a MapLite (tm) that can be customized with hooks.
Obviously to avoid infinite regress, the MapLite bottoms out as native, and
the hooks are on the outside (in Map). Tab, do I have this right?
On Tue, Jul 30, 2013 at 7:15 PM, Brandon Benvie bben...@mozilla.com wrote:
I fully admit that this may be overkill to support an edge case, and as I
said I don't even know if it's expected for multi-realm usage to happen.
Nodes moving between documents (with their own globals) is certainly
Brendan Eich wrote:
I just mean an instance of a Map or a class that extends Map.
Essentially all I'm saying is that you match by [[Class]] (which
doesn't exist in ES6, but a heuristic to determine what is
essentially [[Class]] does exist).
defineOperator('+', addPointAndArray, Point,
On 7/30/2013 9:39 AM, Brendan Eich wrote:
Brendan Eich wrote:
I just mean an instance of a Map or a class that extends Map.
Essentially all I'm saying is that you match by [[Class]] (which
doesn't exist in ES6, but a heuristic to determine what is
essentially [[Class]] does exist).
On Mon, Jul 29, 2013 at 3:12 PM, Brendan Eich bren...@mozilla.com wrote:
๏̯͡๏ 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
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
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
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
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
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
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
See http://www.slideshare.net/BrendanEich/value-objects (tweet:
https://twitter.com/BrendanEich/status/360538755309912064), in
particular slide 13:
typeof travails and travesties
• Invariant -- these two imply each other in JS:
• typeof x == typeof y x == y
• x === y
• 0m == 0 0L == 0
Apologies for something (Postbox?) stripping horizontal spaces out of
that ASCII-art table. Retrying.
/be
Per-real typeof customization API, for two use-cases:
* Value objects (http://www.slideshare.net/BrendanEich/value-objects)
* Opt-in typeof null fixing and unfixing.
Two Map instances,
At the TC39 meeting on Thursday, I joked to Mark (deadpan) that the
typeof registry is as good as the global object. That got big laughs,
but seriously, it's better. Apart from the null special-case, it's like
a global object where only const is allowed. You can't redefine typeof
-- first to
Brendan Eich wrote:
Function.setTypeOf(V, U)
1. Let S = ToString(U)
2. Let T = V
3. If T is null then
3a. If S is not null and S is not object, throw
4. Else
4a. If T is not a value object constructor, throw
4b. T = T.prototype
4c. If TypeofToExemplarMap.has(S), throw
5. Call
Suggestion: put this evolving spec into a Gist or something similar.
On Jul 28, 2013, at 23:24 , Brendan Eich bren...@mozilla.com wrote:
Brendan Eich wrote:
Function.setTypeOf(V, U)
1. Let S = ToString(U)
2. Let T = V
3. If T is null then
3a. If S is not null and S is not object,
Axel Rauschmayer wrote:
Suggestion: put this evolving spec into a Gist or something similar.
Definitely -- trying not to work all weekend, s'all. Also practicing
release-early/often on es-discuss.
Thanks for reading! Any other comments?
/be
On Jul 28, 2013, at 23:24 , Brendan Eich
1. Absolutely love the multiple dispatch stuff (slide 10).
2. A bit uneasy about typeof, which will never properly express JavaScript’s
“class” hierarchy. That is bound to always confuse people (already: “wait – I
thought a function was an object”, worse with value objects). But maybe it’s
the
Axel Rauschmayer wrote:
1. Absolutely love the multiple dispatch stuff (slide 10).
2. A bit uneasy about typeof, which will never properly express
JavaScript’s “class” hierarchy.
What class hierarchy? primitives have wrappers but those are not what
typeof tests. If you believe
[Mangled ASCII art again, sorry for the
resend. Slight edit below, you'd have to diff to catch it. /be]
Axel Rauschmayer wrote:
1. Absolutely love the multiple dispatch stuff (slide 10).
2. A bit uneasy about typeof, which will never properly express
_javascript_’s “class” hierarchy.
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 my complaint is better
69 matches
Mail list logo
