domenic at domenicdenicola.com (2013-07-24T00:09:12.428Z)
On Wed, Jul 17, 2013 at 9:11 AM, Brendan Eich <brendan at mozilla.com> wrote: >>> Users do not want more wrappers, e.g., Uint64 for uint64. No use-case is served by such beasts. >>> >>> You might argue that "total cognitive load" is lower, but I reply that since wrappers are almost completely unobservable and not used explicitly, the load of having two types, symbol/Symbol, bignum/Bignum, etc., is strictly higher. > > I'm hoping you agree here! I do. But the direction we're going does have a complexity cost. All new "types" of things, whether symbols or bignums or whatever, should be new object types, where we introduce a further distinction between "value" objects (need a better word) which are immutable and compare based on contents (bignums) vs unique objects which compare based on unforgeable EQness identity. Curiously, symbols are unforgeable, and so are in the latter camp. I am uncomfortable expanding the typeof namespace. Where do these new names come from, and how do we avoid collision?
On Wed, Jul 17, 2013 at 9:11 AM, Brendan Eich <brendan at mozilla.com> wrote: > Mark S. Miller wrote: > > On Wed, Jul 17, 2013 at 8:55 AM, Brendan Eich <brendan at mozilla.com<mailto: >> brendan at mozilla.com>> wrote: >> >> Andreas Rossberg wrote: >> >> As said above, we already have the primitive case, and you are >> just >> adding yet another kind of beast. I don't think that would be >> improving anything. On the contrary. >> >> >> This is an argument from minimization of primitive concepts or >> kinds, but I argue the better way on the web (given backward >> compatibility) is not to mimimize at such a reductive level. Users >> mostly ignore the boolean, number, and string wrappers, which are >> unobservable in strict mode. >> >> >> Nit: They are not unobservable. Rather, strict code itself never >> implicitly wraps. >> > > Thanks, I meant that, but my point is users really don't run into > boolean/Boolean, number/Number, and string/String complexity in the main. > Yes, one must use String.prototype (not string.prototype, there's no > 'string' of course), but such minor irregularities in languages are a > lesser issue. > > > However, for example, >> >> ({}).valueOf.call(3) // 3 wrapper >> > > Right. > > > >> Users do not want more wrappers, e.g., Uint64 for uint64. No >> use-case is served by such beasts. >> >> You might argue that "total cognitive load" is lower, but I reply >> that since wrappers are almost completely unobservable and not >> used explicitly, the load of having two types, symbol/Symbol, >> bignum/Bignum, etc., is strictly higher. >> >> > I'm hoping you agree here! I do. But the direction we're going does have a complexity cost. All new "types" of things, whether symbols or bignums or whatever, should be new object types, where we introduce a further distinction between "value" objects (need a better word) which are immutable and compare based on contents (bignums) vs unique objects which compare based on unforgeable EQness identity. Curiously, symbols are unforgeable, and so are in the latter camp. I am uncomfortable expanding the typeof namespace. Where do these new names come from, and how do we avoid collision? > > > /be > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130717/114a61a1/attachment.html>