Re: Terminology: types, constructors, classes, …

Dean Landolt dean at
Sun Oct 23 10:29:46 PDT 2011

On Sun, Oct 23, 2011 at 12:01 PM, Axel Rauschmayer <axel at> wrote:

> - What about primitives?Are there primitive types and object types? Is the
>> union of the two called just “types”?
> That seems to be how a lot of folks refer to them, but I think it's a
> little confusing. A primitive type is one that cannot be decomposed any
> further, so Object is a primitive type, and a Function is an object type.
> Almost: a primitive is something that isn’t handled by reference. Object is
> therefore not a primitive type:
> var o1 = new Object();
> var o2 = o1;
> = 123;
> console.log(; // 123

Is that from the spec? My interpretation of "primitive" is from ISO/IEC
11404 (a *surprisingly* good read for a spec about types!): primitive
datatypes are "defined axiomatically without reference to other datatypes"
and goes on to say "All primitive datatypes are conceptually atomic". XSD
similarly defines primitives: "Primitive datatypes are those that are not
defined in terms of other datatypes; they exist ab initio."

What you're defining as primitive is instead the notion of value types, but
it's all kind of jumbled together anyway. To my mind the notion of value vs.
reference types are completely orthagonal, and instead closely related to
mutability. Still, I agree I was wrong to call Objects primitive -- Object
instances are still derived, or generated, or compound, or product, or
whatever (AFAICT the literature is all over the map on this).

> The only thing I am sure of is that "typeof" is unfortunately named :)
> I now use the rule of thumb:
> - typeof: use for primitives and to distinguish primitives from objects.

I'd point out the failure of "null" here but that's being fixed. But your
comments help demonstrate my point, that javascript's type system is

> - instanceof: use for objects.

It's *usable* on objects, but not all that *useful*, even with natives like
Array (they could have come from another frame). This is my biggest problem
with javascript's nominative types. Ducktyping helps, but meh. This is one
reason I'm so excited about private names and the de jure namespace the
module system gives us -- which can help sort this out once and for all.

Obviously, typeof also works for checking for functions.
> You could also say javascript's type lattice is pretty damn degenerate.
> Can you elaborate?

The subtype relation is a partial order -- whether the top and bottom type
are implicit or explicit is language dependent, but as a partial order all
types in a given system can be represented as a lattice. But if you drew the
types of any es5 application as a hasse diagram it would look pretty goofy
-- flat on one side with most of the built-ins nearly impossible to extend,
and then below Object you'd have a tree that sprawls out, with each leaf
bottoming out at falsum. So that's what I meant by a degenerate lattice. And
es-next does offer some help with extending the built-ins, it's type system
will still lack the capabilities to do much else, like derivation by

This is all just speaking to the built-in type system -- obviously any
number of application-level type systems have been layered on top with
various characteristics. This is another problem :-/

> (I do think structural typing could be really useful but I have no idea how
> it could be introduced to the language unobtrusively.)
> Something like this?
>     var Counter = { inc: "function", data: "number" };
>     matchesInterface(anObject, Counter);

You could do that and more with a library today, but you'd just be layering
on *third* incompatible type system. And then we'd have three problems :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list