Page 1 of 3
Buy Now: from your local Amazon
An Idiomatic Approach
- In The Beginning Was The Object
- Real World Objects
- The Function Object
Extract - The Function Object
Extract - Function Object Self Reference
- The Object Expression
- Function Scope, Lifetime & Closure
Extract Scope, Lifetime & Closure
Extract Execution Context ***NEW!
- Parameters, Returns and Destructuring
Extract - Parameters, and Destructuring
- How Functions Become Methods
- Object Construction
Extract: - Object Factories
- The Prototype
Extract - ES2015 Class and Extends
- Inheritance and Type
- The Search For Type
- Property Checking
Buy Now: from your local Amazon
Also by Ian Elliot
Just jQuery: The Core UI
Just jQuery: Events, Async & AJAX
There are some facilities that seem to provide some sort of replacement for the idea of type and inheritance, and these are the subject of this chapter.
In particular we look at the constructor and its associated prototype object as substitutes for an object's type and how instanceof attempts to provide something like subtypes.
There are so many problems with all of these approaches that, to an extent, the purpose of this chapter is to point out how they fail so that if you use them you know what to expect.
Mostly all of the facilities in this chapter are best avoided unless you really understand them and have a use for them.
In the next chapter we look at realtime type checking and some alternatives to typing.
Final version in book
The Constructor As An Object’s "type"
The constructor is the first related object we need to consider because a constructor usually creates multiple identical objects. In this sense a constructor creates multiple instances of the abstract object it was designed to create, and even though it is an object it plays the role of a class.
In fact this cozy picture of a constructor stamping out identical objects isn't necessarily true - but let's assume it is for the moment.
Even object literals can be considered to have Object as their constructor and Object.prototype as their prototype.
If you know an object's constructor then you know the minimum set of properties and methods an object supports, i.e. all of those added by the constructor and all of those added by the prototype chain set by the constructor.
So there is a very strong sense that the "type" of an object is related to its constructor. If you know an object’s constructor then you can be fairly certain it has a given set of properties, especially if it is frozen or sealed.
Even if you allow dynamic ad-hoc properties, you can still assume that objects created by the constructor have the same minimum set of properties. It is only when you start using the delete operator that things go wrong.
However, even if you do ban the delete operator this isn't absolutely true because a constructor could conditionally add properties.
This creates an object which always has a property x but only has a property y 50% of the time. So if you discover that obj has been created by C you can, delete not withstanding, safely assume that it has a property x but not that it has a property y.
At the end of the day knowing an object's constructor is still your best guide to what properties it should have, but it is far from perfect.
As long as you make the rule that a constructor always creates objects with the same set of properties then it seems reasonable to use the name of the constructor as if it was the object's type.
So, borrowing from class-based language jargon, we can say that:
This isn't good jargon because o and C are two very different objects and to say o is an instance of C suggests that it is somehow similar but it is jargon you will find commonly used.
A much bigger problem is still that the constructor doesn’t have an immutable name, only variable references.