[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