Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 someth

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Le 5 août 2013 à 19:14, Brendan Eich a écrit : > Claude Pache wrote: >> Le 4 août 2013 à 18:23, Brendan Eich 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 "nu

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Claude Pache wrote: Le 4 août 2013 à 18:23, Brendan Eich 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, no-own-prop

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 introspe

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 do

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Le 4 août 2013 à 18:23, Brendan Eich 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, > no-own-property objec

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 wrote: > From a dev standpoint what we need is a clean API to discriminate between > types. Sometimes we

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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'.

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

>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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 isObj

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 b

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Brandon Benvie wrote: On Aug 3, 2013, at 9:03 PM, Brandon Benvie wrote: On Aug 3, 2013, at 8:25 PM, Brendan Eich 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 fo

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Brandon Benvie wrote: On Aug 3, 2013, at 8:25 PM, Brendan Eich 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 t

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Aug 3, 2013, at 9:03 PM, Brandon Benvie wrote: > > > On Aug 3, 2013, at 8:25 PM, Brendan Eich 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 >

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Aug 3, 2013, at 8:25 PM, Brendan Eich 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 face of value obj

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Claude Pache wrote: Le 4 août 2013 à 01:34, Brendan Eich 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) ==

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Claude Pache wrote: Le 4 août 2013 à 01:39, Brendan Eich 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 pat

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Le 4 août 2013 à 01:34, Brendan Eich 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) === >> "numbe

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Le 4 août 2013 à 01:39, Brendan Eich 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 patch

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 f

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 ty

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Le 3 août 2013 à 12:01, David Bruant 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 devs > think.

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 something

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 Function.setT

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Le 03/08/2013 12:01, David Bruant 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 way s/way/weigh/ I can't believe I just made the exact same mistake -_-# in favor of keeping

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 http://wiki.ecmascript.org/doku.php?id=harmony:typeof_nul

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 affects

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Fri, Aug 2, 2013 at 3:02 PM, Allen Wirfs-Brock wrote: > > 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 wi

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 affects subsequent use of ty

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Fri, Aug 2, 2013 at 3:34 PM, Allen Wirfs-Brock 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 concern (T

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 b

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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.

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Fri, Aug 2, 2013 at 12:06 PM, Allen Wirfs-Brock wrote: > On Aug 1, 2013, at 5:36 PM, Tab Atkins Jr. wrote: >> On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich wrote: >>> Tab is still looking for a MapLite (tm) that can be customized with hooks. >>> Obviously to avoid infinite regress, the MapLite

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 objects. The current spec. for MapInterator was writ

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Aug 1, 2013, at 5:36 PM, Tab Atkins Jr. wrote: > On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich 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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Fri, Aug 2, 2013 at 1:21 AM, Brendan Eich 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 which point it will d

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich 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? Right. Map has a medi

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 spec

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 Benvie wrote: I fully admit that this may be overkill to support an edge case, and as I said I don't e

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Tue, Jul 30, 2013 at 7:15 PM, Brandon Benvie 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 something that occurs

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Mon, Jul 29, 2013 at 3:12 PM, Brendan Eich 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 internal

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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). defin

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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, Arr

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Jul 29, 2013, at 5:28 PM, Tab Atkins Jr. wrote: > On Mon, Jul 29, 2013 at 5:20 PM, Brendan Eich 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, a

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 application

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

On Mon, Jul 29, 2013 at 5:20 PM, Brendan Eich 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', etc (basicall

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 loa

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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. Really?

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 ari

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 boo

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 Functi

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 nul

RE: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 p

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

๏̯͡๏ 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 val

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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/** doku.php?id=harmony:typeof

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 wh

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

>> 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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 my

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

>> 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 bet

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

[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. Wha

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 b

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Suggestion: put this evolving spec into a Gist or something similar. On Jul 28, 2013, at 23:24 , Brendan Eich 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", throw

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 Ty

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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

Re: typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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, in

typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

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 ==