[Javascript] "typeOf()" Explicit vs Implicit "typeof"
Troy III Ajnej
trojani2000 at hotmail.com
Mon Feb 13 18:51:55 CST 2012
Who would benefit...,
amateurs, charlatans, professionals, all ?
We already have "duck" vs "static" syntax like == vs ===
and they are both extremely useful, especially the duck
one.
The Dynamic-Type-Conversion-Comparison is of course more
versatile but sometimes there are exceptional cases
where we need a static value comparison so that we are
able compare data in their explicit\current, static state;
Where for our convenience, we already have the static eq.,
operator "===" that makes it possible.
This quality imposes itself as a kind of a Live Script
Convention. A conclusive thought that Live Script has two
main categories of methods which can be divided into two
simple groups: Implicit and Explicit.
For instance an implicit (DOM) method could have been a
method like:
x.inRelationTo(y);
//which is by nature an Implicit method of comparing element
relations in the DOM yielding an explicit 'signal' value.
And we may also have had a Pleiade of its Explicit methods
to complement that:
x.sameNode(y);
x.precedes(y);
x.follows(y);
x.contains(y);
x.contained(y);
x.unrelated(y)
x.expects(y);
x.expected(y); //etc
So having for instance the x.inRelationTo(y) would cover
all cases of explicit ones, but than you would have to
check:
x.inRelationTo(y)=="sameNode";
//instead of explicitly determining
x.sameNode(y); //boolean true:false
Where having one but lacking the other would cut the coders
expression capability by half.
Anyways:
Having two complementary methods for a similar operation
does come as naturally expected quality in Live Sript
and the "typeof" is one of the cases where we experience
a gap, or a lack of its expected static method existence.
The "typeof" doesn't have its "counterpart", probably because
an early days coder was not depending on such explicit checks
very frequently. -But times have changed..., and that's where
we come back to my initial question:
How would you feel about having a complementary method of
the existing 'typeof', which would be able to return explicit
signals like in the following examples:
typeOf(void 0);
>> "undefined"
typeOf(0);
>> "0"
typeOf(1);
>> "1"
typeOf(2);
>> "Number"
typeOf(1.798e308);
>> "Infinity"
typeOf(-5e324);
>> "-Infinity"
typeOf("");
>> "" //empty string
typeOf("abc");
>> "String"
typeOf(33/"a");
>> "NaN"
typeOf([]);
>> "[]" //empty array
typeOf(["a","b"]);
>> "Array"
typeOf({});
>> "{}" //empty or notEnumerable Object
typeOf({1:"a"});
>>"Object"
typeOf(null);
>> "null"
typeOf(!0);
>> "true"
typeOf(!1);
>>"false"
typeOf(/abc/);
>> "RegExp"
With additional capability of determining things like:
typeOf(Date);
>>"Function"
typeOf(Date());
>>"String"
typeOf(new Date);
>> "Date"
And somewhat browser dependent things like:
typeOf(div)
>> "HTMLDivElement"
typeOf(div.children);
>> "HTMLCollection"
etc., would this type of an examiner be a plus or a minus;
would it be more of a help to amateurs or to pro's;
Or would it in fact empower both parties with a new level of confidence
in their everyday coding?
More information about the Javascript
mailing list