Crockford's JavaScript OOP system

Discussion in 'Javascript' started by Peter Michaux, Oct 21, 2007.

  1. Douglas Crockford doesn't seem to like JavaScript's built-in syntax
    for building new objects based on a prototype object. The constructor
    function, its prototype property and the "new" keyword all seem very
    offensive to him. For over a year, Crockford has proposed an alternate
    way of using prototypes like this

    function object(o) {
    function F() {}
    F.prototype = o;
    return new F();
    }
    var newObject = object(oldObject);

    I can see some appeal in Crockford's technique above. I do see some
    inefficiency in the code above as the little dance with F() and its
    prototype needs to occur for every object created.

    What concerns me more is his suggested use in the above link of
    object() function in combination with what he calls "maker functions"
    and "parasitic inheritance".

    -------

    When I first watched Crockford speak about parasitic inheritance it
    took something similar to the following form where person() and
    employee() are maker functions.

    function person(first) {
    return {
    first: first,
    getName: function() {
    return this.first;
    }
    };
    }

    function employee(first, position) {
    var that = person(first);
    that.position = position;
    that.getPosition = function () {
    return this.position;
    };
    return that;
    }

    var giselle = employee("Giselle", "hot model");
    giselle.getName();

    The above code is inefficient as the functions objects referenced by
    the getName and getPosition are not shared by all employee objects.
    This leads to triple memory use compared with a standard JavaScript
    formulation using a function as a constructor with the getName and
    getPosition functions as properties of the constructor's prototype.

    -------

    Now Crockford is recommending his prototypal system with the object()
    function in combination with parasitic inheritance. I haven't seen
    clear examples where he is augmenting functions in the "prototype
    object chain". It seems he has used parasitic inheritance more for
    augmenting non-function valued properties: building up a hash. I am
    not clear how Crockford would implement his recommendation with
    multiple levels of makers where functions are augmented but he does
    mention "secret" variables and privileged function properties. This
    seems to lead in the direction of inefficiencies of the parasitic
    example above where the privilaged function objects cannot be shared.

    ------

    A while ago I played with using prototypes a different way than I
    normally do to really emphasis the building up of complete prototype
    objects. Below is my thinking translated to use Crockford's object()
    function. In this way the getName and getPosition functions are shared
    in memory.

    function object(o) {
    function F() {}
    F.prototype = o;
    return new F();
    }

    // build up a prototypical person
    var adam = {
    first: 'Adam',
    getName: function() {
    return this.first;
    }
    }

    // a person maker function
    function person(first) {
    var p = object(adam);
    p.first = first;
    return p;
    }

    // build up a prototypical employee
    var homer = person('homer');
    homer.position = 'safety';
    homer.getPosition = function() {
    return this.position;
    }

    // an employee maker function
    function employee(first, position) {
    var e = object(homer);
    e.first = first;
    e.position = position;
    return e;
    }

    var giselle = employee("Giselle", "hot model");
    giselle.getName();

    ---------

    The above example could easily be written in the normal JavaScript way
    without the need for the object() function.

    var adam = {
    first: 'Adam',
    getName: function() {
    return this.first;
    }
    }

    function Person(first) {
    this.first = first;
    }
    Person.prototype = adam;

    var homer = new Person('homer');
    homer.position = 'safety';
    homer.getPosition = function() {
    return this.position;
    }

    function Employee(first, position) {
    this.first = first;
    this.position = position;
    }
    Employee.prototype = homer;

    var giselle = new Employee("Giselle", "hot model");
    giselle.getName();


    It seems to me that this last example is quite similar to the previous
    example. This example is, in fact, more declarative than the previous
    example because in this last example there are lines like
    "Person.prototype = adam;" which says what it means quite clearly.
    This example is also more efficient (although perhaps just slightly)
    without the need for the "F() dance" in object(). This example uses
    language-level constructs which which JavaScript programmers are
    familiar. Even disregarding the object() function's length, this
    example is shorter.

    -------

    Do you see advantages to using Crockford's object() function?

    Do you see the apparent ugliness that Crockford seems to see in the
    JavaScript built-in system of constructor functions, their prototype
    objects and the "new" keyword?

    Is there precedence for Crockford's object() function from another
    language?

    Should the JavaScript language have an facility like Crockford's?
    object() function?

    How would you code this Person-Employee example?

    If you happen to be Douglas Crockford, how badly have I misinterpreted
    your writing and speaking?

    ======================================================

    REFERENCES

    Crockford's page containing the object() function
    <URL: http://javascript.crockford.com/prototypal.html>

    Crockford's page mentioning parasitic inheritance
    <URL: http://javascript.crockford.com/inheritance.html>

    Crockford videos mentioning parasitic inheritance
    See the "Advanced JavaScript" series on YUI blog
    <URL: http://developer.yahoo.com/yui/theater/>

    JSLint
    <URL: http://jslint.com>

    Crockford's Top Down Operator Precedence article
    Precursor to his chapter in "Beautiful Code"?
    <URL: http://javascript.crockford.com/tdop/tdop.html>
    Peter Michaux, Oct 21, 2007
    #1
    1. Advertising

  2. Peter Michaux wrote:
    > Douglas Crockford doesn't seem to like JavaScript's built-in
    > syntax for building new objects based on a prototype object.
    > The constructor function, its prototype property and the
    > "new" keyword all seem very offensive to him.
    > For over a year, Crockford has proposed an alternate
    > way of using prototypes like this
    >
    > function object(o) {
    > function F() {}
    > F.prototype = o;
    > return new F();
    > }
    > var newObject = object(oldObject);
    >
    > I can see some appeal in Crockford's technique above. I do
    > see some inefficiency in the code above as the little
    > dance with F() and its prototype needs to occur for every
    > object created.


    The assigning to the prototype does need to happen every time, but I
    don't see why it is necessary to have a new constructor created for each
    execution of the function. It would not seem too much trouble to write
    it as:-

    var object = (function(){
    function F(){}
    return (function(o){
    F.prototype = o;
    return new F();
    });
    })();

    - and re-use a single constructor.

    > What concerns me more is his suggested use in the above
    > link of object() function in combination with what he
    > calls "maker functions" and "parasitic inheritance".
    >
    > -------
    >
    > When I first watched Crockford speak about parasitic
    > inheritance it took something similar to the following
    > form where person() and employee() are maker functions.
    >
    > function person(first) {
    > return {
    > first: first,
    > getName: function() {
    > return this.first;
    > }
    > };
    > }
    >
    > function employee(first, position) {
    > var that = person(first);
    > that.position = position;
    > that.getPosition = function () {
    > return this.position;
    > };
    > return that;
    > }
    >
    > var giselle = employee("Giselle", "hot model");
    > giselle.getName();
    >
    > The above code is inefficient as the functions objects
    > referenced by the getName and getPosition are not shared
    > by all employee objects. This leads to triple memory use
    > compared with a standard JavaScript formulation using a
    > function as a constructor with the getName and getPosition
    > functions as properties of the constructor's prototype.


    That isn't the only way of getting rid of the needless creation of
    multiple functions instances:-

    var person = (function(){
    function forGetName(){
    return this.first;
    }
    return (function(first){
    return ({
    first:first,
    getName:forGetName
    });
    });
    })();

    var employee = (function(){
    function forGetPosition(){
    return this.position;
    }
    return (function(first, position){
    var that = person(first);
    that.position = position;
    that.getPosition = forGetPosition;
    return that;
    });
    })();

    var giselle = employee("Giselle", "hot model");
    giselle.getName();

    - but I can certainly see why an example like may seem inappropriate in
    an example that was talking about styles of inheritance.

    > -------
    >
    > Now Crockford is recommending his prototypal system with
    > the object() function in combination with parasitic
    > inheritance. I haven't seen clear examples where he is
    > augmenting functions in the "prototype object chain". It
    > seems he has used parasitic inheritance more for augmenting
    > non-function valued properties: building up a hash. I am
    > not clear how Crockford would implement his recommendation with
    > multiple levels of makers where functions are augmented but he
    > does mention "secret" variables and privileged function
    > properties. This seems to lead in the direction of
    > inefficiencies of the parasitic example above where the
    > privilaged function objects cannot be shared.


    It is in the nature of 'privileged' functions that they must be unique
    (have a one-to-one relationship with the closured used to store the
    'private' variables/methods. The inefficiency above comes from the fact
    that these examples are not really 'privileged' functions and could be
    shared.

    It may be that you are seeing code that is intended only to be
    illustrative of one possibility in javascript as being intended to be
    specifically definitive of the intended application of that possibility.
    That seems to be what happened with "Crockford's module pattern", where
    individuals observed one illustration of the possibility (a 'singleton'
    implementation) and took that as definitive of the module pattern, and
    then expended their effort 'creating' (and naming) specific variations,
    where such variations had always been inherent in the module pattern as
    a whole (and indeed most considerably pre-date 'singleton'
    implementations in the history of the module pattern).

    When writing code that is intended to illustrate something specific it
    is often best to simplify all other aspects of the code (such as those
    that may impact on efficiency) in order to not distract attention form
    what is important to the subject. It is also normal to provide very
    limited numbers of examples (often only one) even when endless
    possibilities would exist.

    > ------
    >
    > A while ago I played with using prototypes a different way
    > than I normally do to really emphasis the building up of
    > complete prototype objects. Below is my thinking translated
    > to use Crockford's object() function. In this way the getName
    > and getPosition functions are shared in memory.
    >
    > function object(o) {
    > function F() {}
    > F.prototype = o;
    > return new F();
    > }
    >
    > // build up a prototypical person
    > var adam = {
    > first: 'Adam',
    > getName: function() {
    > return this.first;
    > }
    > }
    >
    > // a person maker function
    > function person(first) {
    > var p = object(adam);
    > p.first = first;
    > return p;
    > }
    >
    > // build up a prototypical employee
    > var homer = person('homer');
    > homer.position = 'safety';
    > homer.getPosition = function() {
    > return this.position;
    > }
    >
    > // an employee maker function
    > function employee(first, position) {
    > var e = object(homer);
    > e.first = first;
    > e.position = position;
    > return e;
    > }
    >
    > var giselle = employee("Giselle", "hot model");
    > giselle.getName();
    >
    > ---------
    >
    > The above example could easily be written in the normal
    > JavaScript way without the need for the object() function.
    >
    > var adam = {
    > first: 'Adam',
    > getName: function() {
    > return this.first;
    > }
    > }
    >
    > function Person(first) {
    > this.first = first;
    > }
    > Person.prototype = adam;
    >
    > var homer = new Person('homer');
    > homer.position = 'safety';
    > homer.getPosition = function() {
    > return this.position;
    > }
    >
    > function Employee(first, position) {
    > this.first = first;
    > this.position = position;
    > }
    > Employee.prototype = homer;
    >
    > var giselle = new Employee("Giselle", "hot model");
    > giselle.getName();
    >
    >
    > It seems to me that this last example is quite similar to the
    > previous example. This example is, in fact, more declarative
    > than the previous example because in this last example there
    > are lines like "Person.prototype = adam;" which says what it
    > means quite clearly.


    Maybe, in the sense that it says something, but I don't see any need to
    have an 'adam' object at all. It may as well just be an (anonymous)
    object assigned to Person.prototype. Indeed this strikes me as the more
    normal javascript prototype inheritance approach to this code:-

    function Person(first) {
    this.first = first;
    }
    Person.prototype = {
    first:'',
    getName:function() {
    return this.first;
    }
    };

    function Employee(first, position) {
    this.first = first;
    this.position = position;
    }
    Employee.prototype = new Person('');
    Employee.prototype.position = 'safety';
    Employee.prototype.getPosition = function() {
    return this.position;
    };

    > This example is also more efficient (although perhaps just
    > slightly) without the need for the "F() dance" in object().
    > This example uses language-level constructs which which
    > JavaScript programmers are familiar. Even disregarding
    > the object() function's length, this example is shorter.
    >
    > -------
    >
    > Do you see advantages to using Crockford's object() function?


    Yes (though I would perceive it as Lasse Reichstein Nielsen's "clone"
    function, and write it the way I illustrated above (or using the
    'Russian Doll' pattern)), but it serves a specific purpose and is not a
    universal panacea for inheritance.

    There is a great deal to be said for 'inheriting' form specific object
    instances. In the system I work with it is necessary to employ multiple
    instances of fairly complex object that individually have complex
    one-time set-up operations and a re-occurring configuration phase, but
    are such that it is possible (indeed likely) that more than one instance
    will exist at a time which should have undergone the same one-time
    set-up. I speed this process up by having the system recognise when an
    object already exists that has undergone the necessary one-time set-up
    and then just uses that object as the prototype of a new object, with
    the re-occurring configuration acting to mask the instance specific
    aspects of the object being inherited from.

    > Do you see the apparent ugliness that Crockford seems to
    > see in the JavaScript built-in system of constructor
    > functions, their prototype objects and the "new" keyword?


    The traditional object defining structures are a little "ragged" in my
    opinion.

    > Is there precedence for Crockford's object() function from
    > another language?


    I don't know (as it would have to be a language that uses prototype
    inheritance and I don't know how to use any others).

    > Should the JavaScript language have an facility like
    > Crockford's? object() function?


    The javascript language has a facility like "Crockford's object
    function", else you could not see it above.

    > How would you code this Person-Employee example?


    What is the specification?

    > If you happen to be Douglas Crockford, how badly have
    > I misinterpreted your writing and speaking?

    <snip>

    Richard.
    Richard Cornford, Oct 21, 2007
    #2
    1. Advertising

  3. On Oct 21, 2:12 pm, "Richard Cornford" <>
    wrote:
    > Peter Michaux wrote:


    <snip>

    > > A while ago I played with using prototypes a different way
    > > than I normally do to really emphasis the building up of
    > > complete prototype objects. Below is my thinking translated
    > > to use Crockford's object() function. In this way the getName
    > > and getPosition functions are shared in memory.

    >
    > > function object(o) {
    > > function F() {}
    > > F.prototype = o;
    > > return new F();
    > > }

    >
    > > // build up a prototypical person
    > > var adam = {
    > > first: 'Adam',
    > > getName: function() {
    > > return this.first;
    > > }
    > > }

    >
    > > // a person maker function
    > > function person(first) {
    > > var p = object(adam);
    > > p.first = first;
    > > return p;
    > > }

    >
    > > // build up a prototypical employee
    > > var homer = person('homer');
    > > homer.position = 'safety';
    > > homer.getPosition = function() {
    > > return this.position;
    > > }

    >
    > > // an employee maker function
    > > function employee(first, position) {
    > > var e = object(homer);
    > > e.first = first;
    > > e.position = position;
    > > return e;
    > > }

    >
    > > var giselle = employee("Giselle", "hot model");
    > > giselle.getName();

    >
    > > ---------

    >
    > > The above example could easily be written in the normal
    > > JavaScript way without the need for the object() function.

    >
    > > var adam = {
    > > first: 'Adam',
    > > getName: function() {
    > > return this.first;
    > > }
    > > }

    >
    > > function Person(first) {
    > > this.first = first;
    > > }
    > > Person.prototype = adam;

    >
    > > var homer = new Person('homer');
    > > homer.position = 'safety';
    > > homer.getPosition = function() {
    > > return this.position;
    > > }

    >
    > > function Employee(first, position) {
    > > this.first = first;
    > > this.position = position;
    > > }
    > > Employee.prototype = homer;

    >
    > > var giselle = new Employee("Giselle", "hot model");
    > > giselle.getName();

    >
    > > It seems to me that this last example is quite similar to the
    > > previous example. This example is, in fact, more declarative
    > > than the previous example because in this last example there
    > > are lines like "Person.prototype = adam;" which says what it
    > > means quite clearly.

    >
    > Maybe, in the sense that it says something, but I don't see any need to
    > have an 'adam' object at all.


    Neither do I. It was more an exercise to try and focus on complete
    prototypes perhaps in a philosophical sense. I don't imagine Plato or
    Aristotle idealizing a partial horse prototype with certain details
    filled in by all instances based on that prototype. The way that a
    constructor function's prototype object is usually used in JavaScript
    is a bit of a template pattern. For example, the person prototype
    wouldn't necessarily have a name property but would have the ability
    to say its name which is a bit odd.


    > It may as well just be an (anonymous)
    > object assigned to Person.prototype. Indeed this strikes me as the more
    > normal javascript prototype inheritance approach to this code:-


    I should not have written that the above is "normal JavaScript." I
    should have written the second version is closer to the normal
    JavaScript way of doing things using the prototype property of the
    constructor and "new".


    > function Person(first) {
    > this.first = first;}
    >
    > Person.prototype = {
    > first:'',
    > getName:function() {
    > return this.first;
    > }
    >
    > };
    >
    > function Employee(first, position) {
    > this.first = first;
    > this.position = position;}
    >
    > Employee.prototype = new Person('');
    > Employee.prototype.position = 'safety';
    > Employee.prototype.getPosition = function() {
    > return this.position;
    >
    > };


    I agree that your code above is almost exactly what is usually
    considered normal JavaScript.

    The things that bother me about examples like these are the
    duplication of the initialization of the person (ie
    "this.first=first;") in the Employee function. There are several ways
    to factor this out of the Person() function and then call this
    initialization code from both constructors however no particular
    technique I've tried has struck me as elegant.

    Also sending the empty string in the "new Person('')" line.
    Crockford's technique and several others that use dummy constructors
    (ie F()) avoid this which I think is probably good.


    <snip>

    > > Do you see advantages to using Crockford's object() function?

    >
    > Yes (though I would perceive it as Lasse Reichstein Nielsen's "clone"
    > function,


    I'll search the archives sometime for this. The first time in
    encountered this sort of function it helped when I realized it was a
    "live clone" and changes to the prototype continued to affect the
    clones.

    <snip>

    Thanks for your thoughts, Richard.

    Peter
    Peter Michaux, Oct 22, 2007
    #3
  4. Peter Michaux

    Brian Adkins Guest

    On Oct 21, 5:12 pm, "Richard Cornford" <> >
    The assigning to the prototype does need to happen every time, but I
    > don't see why it is necessary to have a new constructor created for each
    > execution of the function. It would not seem too much trouble to write
    > it as:-
    >
    > var object = (function(){
    > function F(){}
    > return (function(o){
    > F.prototype = o;
    > return new F();
    > });
    >
    > })();
    >
    > - and re-use a single constructor.


    FYI - I ran a simple benchmark (below), and the execution time (best
    of 5 runs) using Crockford's version was 37% longer than yours. That's
    a pretty significant speedup.

    var foo = {};
    var bar = null;
    var t1 = new Date();
    for (var i = 0; i < 300000; ++i) {
    bar = object(foo);
    }
    var t2 = new Date();
    alert ('elapsed time = ' + (t2.getTime() - t1.getTime()) + ' ms');
    Brian Adkins, Oct 29, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    1,019
  2. Peter Michaux
    Replies:
    1
    Views:
    117
    Randy Webb
    Oct 29, 2006
  3. lorlarz
    Replies:
    81
    Views:
    556
    Jeremy J Starcher
    Aug 22, 2008
  4. Jorge
    Replies:
    10
    Views:
    205
    Jorge
    Feb 18, 2010
  5. Jorge
    Replies:
    6
    Views:
    105
    Dr J R Stockton
    Mar 11, 2010
Loading...

Share This Page