On Sun, Oct 23, 2011 at 12:01 PM, Axel Rauschmayer <a...@rauschma.de> 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; > o1.foo = 123; > console.log(o2.foo); // 123 > > http://www.2ality.com/2011/03/javascript-values-not-everything-is.html > 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 bifurcated. > - 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 restriction. 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 :)
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
