A streamlined non-disturbing class possibility

# Herby Vojčík (14 years ago)

With .{...} around, I wonder, do we really need special class construct with its own structure? I think with a little set of changes, minimal, well-blended solution would be possible:

  1. Allow <| for function declarations.

    SuperFun <| function fun(...) { ... }

  2. Allow .{} for function declarations.

    function gz(compress=false, blob) { ... }.{ GZIP := 2, // := is const member as in actual proposal DEFLATE := 4 }

  3. Define keyword 'class' to do exact same thing as function (declare function or return expression; setting up empty prototype and constructor property in it), with only one difference - it's completion value will be the prototype, not the constructor.

    Animal <| class Fox (...) { // instance initialzation }.{ // instance-shared behaviour (aka prototype) }

    Fox.{ // optionally some static ones }

Class-private is the only hard thing. Well, I'd be able to live without it. Just put a private keyword before the class declaration. No big issue, if you want to reuse later, you will, if not, you will not; just don't export it; it will be local to the scope in which class was defined, it may be enough.

# Rick Waldron (14 years ago)
# Herby Vojčík (14 years ago)

Rick Waldron wrote:

Similar discussion here:

www.mail-archive.com/[email protected]/msg10692.html

Thank you, I wasn't here yet at the time. From what I saw, it did a f(){}.prototype.{} or the like. It is the basic idea, but confusing, the .prototype.{... is not good.

What I tried, is to make it so it can fulfill the primary "class" goal - to create syntactic structure which people coming from class languages can take and use without too much hassle, while at the same time doing it so it is blended into the matter of the language well.

The twist of "class being a function equivalent returning the prototype" could do it (when <| is allowed for declarations). This:

  Animal <|
  class Fox (...) {
    // instance initialzation
  }.{
    // instance-shared behaviour (aka prototype)
  }

  Fox.{
    // optionally some static ones
  }

is pretty sleak; the class (sans statics which are not so criticial) is defined in one piece of code with only a handful of rules, having only one keyword (class) and rest is "syntax". It can be copied as-is by beginniners and later understood that both <| and .{...} are in fact nothing special.

# Herby Vojčík (14 years ago)

Herby Vojčík wrote:

With .{...} around, I wonder, do we really need special class construct with its own structure? I think with a little set of changes, minimal, well-blended solution would be possible:

  1. Allow <| for function declarations.

SuperFun <| function fun(...) { ... }

  1. Allow .{} for function declarations.

function gz(compress=false, blob) { ... }.{ GZIP := 2, // := is const member as in actual proposal DEFLATE := 4 }

Forgot this:

2.5 Allow super everywhere it has meaning.

In any constructor function Fun, allow an expression "super(x, y)" acting like Fun.[[Prototype]].call(this, x, y), as if using the original binding of Function.prototype.call.

In any method extending object p, allow an expression "super.member(z, w)" acting like p.[[Prototype]].member.call(this, z, w), as if using the original binding of Function.prototype.call.