ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

> -----Original Message-----
> From: Garrett Smith [mailto:dhtmlkitchen at gmail.com]
> Sent: Friday, July 18, 2008 10:31 AM
...
> >
> > Neither Object.create nor Object.clone was not intended to be a
> directly replacement for Object.extend.
>

Make that:
        Neither Object.create or Object.clone were intended to be a direct replacement for Object.extend.
Or
        Object.create and Object.clone were not intended to directly replace Object.extend.
My brain clearly hadn't decided which formulation it was trying to spew.

The reason I would say either of the above, is that I think of both Object.create and Object.clone as primarily object instantiation functions (factories, if you prefer) and that my preference is to factor common behavioral properties (eg, methods and getters/setters) into shared "parents" on the prototype chain rather than copying them into multiple instances. Similarly, my preference for "data" properties (eg instance variable) is to define them when an object is first instantiated, rather than lazily as they are assigned to.  (BTW, these preference are significantly influences by the optimization opportunities they create for a smart implementation)

To get more concrete, if I was going to implement the ECMAScript equivalent of a classic point abstraction, I would define a point parent containing all the methods.  For example:
   const pointBehavior = Object.defineProperties({}, {
      add: {
        enumerable: false, writable: false, flexible: false,
        value: function (aPoint} {/**function body omitted**/
            }},
      distance: {
        enumerable: false, writable: false, flexible: false,
        value: function (aPoint} {
            /**function body omitted**/
            }},
      /** other methods ***/
    });

And for the public point factory, I would either define an instance template object (I need to say template because the word "prototype" has too many possible interpretations in the world of ECMAScript) that gets cloned:
   const pointTemplate = Object.create(pointBehavior, {
      x: {value: 0, enumerable: true, writable: true, flexible: false},
      y: {value: 0, enumerable: true, writable: true, flexible: false}
      });
   function makePoint() {return Object.clone(pointTemplate)};

or I would just use create in the factory function:
   function makePoint2() {
      return Object.create(pointBehavior, {
         x: {value: 0, enumerable: true, writable: true, flexible: false},
         y: {value: 0, enumerable: true, writable: true, flexible: false}
         });
      }

or I might must inline the definition of pointBehavior into the above and get:
   function makePoint3() {
      return Object.create(
         Object.defineProperties({}, {
            //methods
            add: {enumerable: false, writable: false, flexible: false,
               value: function (aPoint} {/**function body omitted**/
               }},
            distance: {enumerable: false, writable: false, flexible: false,
              value: function (aPoint} {/**function body omitted**/
               }},
            /** other methods ***/
            },
         {
            //instance variables
            x: {value: 0, enumerable: true, writable: true, flexible: false},
            y: {value: 0, enumerable: true, writable: true, flexible: false}
            }
         );
      }

Now, I admit that I'm using Object.create to define the template object and that I could have used it to define the behavior object, but I rationalize that to myself as the act of instantiating a couple of singleton objects so I'm still using Object.create primarily as an instantiation function. Regardless, my sense that this style is different from what people are talking about WRT using Object.extend for injecting mix-in behaviors.

BTW, please consider the above to be part of my answer to essay question #3 that I posed in an earlier post today.