On Sun, Jan 1, 2012 at 12:12 AM, John J Barton
<johnjbar...@johnjbarton.com>wrote:
>
>
> On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer <a...@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
>> a...@rauschma.de
>>
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
