Discuss
  • A variation of Allen’s Class Definition Pattern

A variation of Allen’s Class Definition Pattern

# Axel Rauschmayer (14 years ago)

harmony:object_extension_literal_class_pattern

I like the Class Definition Pattern and tried to make it more flexible:

const className = superClass <| function(/*constructor parameters */) {
    //constructor body
    super.constructor(/*arguments to super constructor */);
    this.{
     //per instance property definitions
    };
}.withPrototype({
    //instance properties defined on prototype
}).withProperties({
    //class (ie, constructor) properties
});

  • Approach: Define two methods Function.prototype.withPrototype() and Function.prototype.withProperties(). The latter task could also be performed via the object extension operator – I used a method for reasons of symmetry. Both methods return "this".

  • Advantages compared to using the object extension operator:

    • Can omit the class property definition (without having to append ".constructor").
    • Both “clauses” can be swapped.
# Brendan Eich (14 years ago)

On Sep 25, 2011, at 7:52 PM, Axel Rauschmayer wrote:

harmony:object_extension_literal_class_pattern

I like the Class Definition Pattern and tried to make it more flexible:

const className = superClass <| function(/*constructor parameters */) {
    //constructor body
    super.constructor(/*arguments to super constructor */);
    this.{
     //per instance property definitions
    };
}.withPrototype({
    //instance properties defined on prototype
}).withProperties({
    //class (ie, constructor) properties
});

  • Approach: Define two methods Function.prototype.withPrototype() and Function.prototype.withProperties(). The latter task could also be performed via the object extension operator – I used a method for reasons of symmetry. Both methods return "this".

  • Advantages compared to using the object extension operator:

    • Can omit the class property definition (without having to append ".constructor").
    • Both “clauses” can be swapped.

It's hard to object. The problem is that this requries a library (whether standardized into built-ins or not), and it is imperative as all get-out.

I still think class syntax has a place, but it has to be super-sweet, no verbose syntax gaffes or near-misses or brushes-with-greatness-that-landed-on-merely-good. We ain't there yet.

# John J Barton (14 years ago)

On Sun, Sep 25, 2011 at 8:18 PM, Brendan Eich <brendan at mozilla.com> wrote:

... and it is imperative as all get-out.

I realize this is supposed to be common knowledge, but I would appreciate a pointer to why 'imperitive' gets listed as a negative. In my experience declarative is only good for toy programs. Maybe I am mixing up 'declarative language' and 'declarative syntax in a language'?

jjb

# Brendan Eich (14 years ago)

On Sep 25, 2011, at 9:20 PM, John J Barton wrote:

On Sun, Sep 25, 2011 at 8:18 PM, Brendan Eich <brendan at mozilla.com> wrote:

... and it is imperative as all get-out.

I realize this is supposed to be common knowledge, but I would appreciate a pointer to why 'imperitive' gets listed as a negative. In my experience declarative is only good for toy programs. Maybe I am mixing up 'declarative language' and 'declarative syntax in a language'?

I think so.

JS functions are declarative forms. They have binding effects before evaluation of expressions and statements in the containing function or program. This is a good thing.

Object and array literals in ES5 and reality are expression forms but compound, with declarative aspects: the property names are compile-time constants, the newborn object or array cannot escape and be witnessed partially initialized, prototype setters or proxies cannot intercept initializing assignments. These are good things.

en.wikipedia.org/wiki/Imperative_programming, en.wikipedia.org/wiki/Declarative_programming, en.wikipedia.org/wiki/Functional_programming

JS is multi-paradigm.

# Axel Rauschmayer (14 years ago)

I still think class syntax has a place, but it has to be super-sweet, no verbose syntax gaffes or near-misses or brushes-with-greatness-that-landed-on-merely-good.

So do I. This wasn’t meant as an objection to class literals (which I prefer to the above pattern, but not by much – gotta love how well all the object literal extensions fit together).