ES6 doesn't need opt-in

Dean Landolt dean at deanlandolt.com
Sun Jan 1 06:32:41 PST 2012


On Sun, Jan 1, 2012 at 12:12 AM, John J Barton
<johnjbarton at johnjbarton.com>wrote:

>
>
> On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer <axel at rauschma.de>wrote:
>
>> 1. We want sane isObject and isNull predicates, ideally using typeof.
>> Lack of them continues to bite people, as the web contains code that
>> wrongly assumes typeof x == "object" => x.foo won't throw on null x.
>>
>>
>> What are the use cases for typeof? Offhand, I see five and for most of
>> them, other solutions seem to be better.
>>
>
> In my experience the major use of typeof is to implement dynamic function
> overloading.  That is, a function that is flexible in the arguments it
> takes, such that one logical name maps to multiple use cases.
>
>
>>
>> 1. Checking whether a variable has been declared.
>>     Problematic: verbose and conflated with checking for a declared
>> variable having the value `undefined`.
>>     Better: a dedicated operator or predicate for performing this check.
>>
>
> Sorry, I don't think anyone checks if a is variable declared. You just
> look at the source code.
>


Tell that to people writing feature detection code :)



> 2. Checking that a value is neither null nor undefined.
>>     Problematic: can’t be done via only typeof currently.
>>     Better: a predicate for performing this check. This use case will
>> become less important with default parameter values.
>>
>
> if(!name) {}
>


And if name is 0? Or ""? Whoops. Javascript's coercion is pretty winful
here (in spite of what jslint might say): `if (name == null)` is more
targeted, just catching the name === null and name === void 0 cases.


3. Distinguishing between objects and primitives.
>>     Problematic: Made more difficult by typeof null === "object" and
>> typeof function () {} === "function".
>>      Better: predicates such as isObject() and isPrimitive()
>>
>
> Mostly we are checking string, array, function or object.  Only Java devs
> pass/return |null| so that case is not that big of a deal. Or another way
> to look at it: if you use null, it's your own little signal, so enjoy.
>


Again, some people write generic code. Sure, those people should be more
aware of the jswtfs but we can't just pretend they're not there.



> Array is the famously difficult case.
>


Until es5 gave us Array.isArray. But yes, array is another branch in the
object-detection code. And like array, everyone has slightly different
object detection rules. It would be a gift if the language were to fix this.


4. Determining the type of a primitive value.
>>     Better: typeof is OK here, but changing it so that typeof null ===
>> "null" would help.
>>
>> 5. Determining the type of a value (primitive or otherwise).
>>     Better: I would want a function, e.g. getTypeName() that works like
>> (null-enabled) typeof for primitives and returns the value of the [[Class]]
>> property for objects.
>>
>
>  This would be great!
>


Agreed. ISTM the best way to reform typeof may be to just punt on it
entirely. This would be a lot easier to do if the language gave us a better
tool for all of these use cases OOTB. And as Axel points out, modules make
it a lot easier for the language to give us these tools.

>
>
>>
>> Everything except #1 can be easily implemented as functions (and be
>> brought to ES5 via shims). A function such the #5 getTypeName() could take
>> care of use case #4, as well.
>>
>> Ideas for getTypeName():
>> http://www.2ality.com/2011/11/improving-typeof.html
>>
>>         --
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>>
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120101/3cb073af/attachment.html>


More information about the es-discuss mailing list