Types become more and more important in the framework.

Static typechecking would be very handy. But dynamic type checking with good error messages is a big step forward.

For example, I’d like to figure out whether multiple type parameters can be supported in an elegant way. I already use an array for type parameters but I haven’t yet figured out how to check each type parameter without requiring the object or its type object to hand its parts off to the checker. I’d like to avoid messing with Array, Object, and other standard parts of Javascript.

I wrote mine to make working with higher order functions easier. It was a hack to make the typesystem of javascript stronger. I like to write my code in a functional style.

Good work and thank for sharing. If I used it in a project and extend it, I will leave you a message. Cheers.

var test = T.typedFunction(
  {x: T.StringType, y: T.StringType, z: T.StringType},
  T.ArrayStringType,
  function(x, y, z) {
    return [x, y, z];
  }
);
test('x', 'y', 'z') // -> ['x', 'y', 'z']
test(1, 'x', 'z') // -> Error: Parameter x does not satisfy type condition of type String with condition function condition(obj) { return T.is(obj, this.type); }

Of course they’re quite similar, so your mileage may vary. I guess mine is a bit more verbose, but things like named parameters mean that my error messages are quite nice.

You’ll notice that the error talks about type conditions because typed functions in my system can actually specify not just the simple type but rather the conditions based upon it, such as all sub-types of String, such as if you wrote your own RichString extension to String. The README has more about type conditions and implicit conversions (an implicit conversion is being done from the StringType types I provided to type conditions which test for simple equality with the type).

http://sourceforge.net/projects/jtypesystem/files/

From the documentation:

test = FT(TString, TString, TString, TArray,
function(x,y,z){
return new Array(x,y,z);
});
/* Ok */
test(‘x’,'y’,'z’);
/* Not ok */
test(1,’x',’z');

However, there are no such things as classes in Javascript. Rather, instanceof tells you whether the left-hand side object is in the right-hand side object’s prototype chain. This is why (new String) instanceof String == true and (new String) instanceof Object == true: both String and Object are in new String‘s prototype chain. Granted, the same would be true if String were a subclass of Object in a class-based inheritance system, but remember that Javascript uses a prototype-based inheritance system and there can and often are subtle differences.

When you use the new operator on a function (say String) in Javascript, it is essentially the same as String.call({}). That is, the String function is being called with an empty object as its this value. This this (excuse the pun) functionality means that you can have something akin to mixins. String.call(Number.call({})) should give you an object with both string and number methods. I haven’t tested this, so I can’t promise it works.

So, returning to your conclusions from the examples, your explanations are spot on except that null really isn’t an object. I believe it’s a mistake in Javascript to return "object" from typeof null. Instead, I believe it is a primitive, not an object, and should return null.

The solution I was hinting at, and still need to blog about, is typed.js, a better, ‘replacement’ type system for Javascript. It will give you consistent, rational type information. For instance, null is always a NullType in my type system.

In javascript, a “type” is different from a “class” (the object it is an instance of). So “typeof” will only return whether it is a number, boolean, string, or object. The “instanceof” operator is meant to be used on objects, to figure out what kind of object it is. So…

typeof null
// returns “object” because this variable is technically a null object
null instanceof null
// well, “null” isn’t an object type (i.e. an type you defined with a constructor)
// I think what we meant was:
null instanceof Object
// returns false, because null is not an instance -> it is the lack of an instance
true instanceof Boolean
// returns false, because true is not an instance of an Object, it is a primitive type
// That explains the last two examples too.

Thanks for the lesson!