Finding a "safety syntax" for classes

Herby Vojčík herby at mailbox.sk
Tue Mar 20 13:23:42 PDT 2012


Russell Leggett wrote:
> We would have to decide what happens if they don't supply a constructor.
> I think we would need a default, and in my mind there are 3 possibilities:
>
>    1. Empty constructor - does nothing.
>    2. Calls super with no args
>    3. Calls super as a pass through
>
> I'm fond of 3, but might be missing some controversial reason for one of
> the others. Personally, I would be willing to take any of them for the
> sake of classes.
>
>             * to call super on a method you have to indicate the method
>         super.move
>             * while not obvious in the example, I would say the class
>         body should
>                   o be its own construct, not just an object literal - this
>
>     -1. See more below.
>
>                     makes it easier to have methods without ,’s and be
>                     future-proof for whatever we might want later
>
>     I have a lot of reasons (gut instinct, too, but also some though
>     experiments on how things get powerful and concise things can be if
>     classes automaticall had all the possibilities of (potientially
>     revved-up) object literals [1]).
>     So I need to see a really strong argument for abandoning the cause
>     of "body of class should be the same as the body of object literal
>     (with possible little numbers of changes)".
>
>
> Ok, lets put it this way - my safety syntax only allows constructor +
> methods, with no commas in between. If commas after methods can be
> elided in object literal extensions then we're still on solid ground, it
> could go either way. What I would argue, though, is that we don't define
> the class body as equivalent to an object literal, there is still too
> much controversy there.
>
>
>     So my -1 holds if you want to add anything that goes beyond the
>     object-literal syntax, and I'd give -0.66 in case where you would
>     restrict it too much.
>
>     If you restrict it to only hold constructor and methods, it is still
>     a compatible (though stripped) object-literal - you can have methods
>     there (constructor is nothing special, just a method named
>     'constructor'; the magic of class keyword grants it [[Construct]]
>     and .prototype created from {} block and according to object literal
>     syntax you can have methods there without comma), so this would be
>     -0.66.
>
>
> Well then I guess its a -0.66 from you, but remember this is the *safety
> syntax*! The battle can rage on later.

Well, I'm ok with this. My primary concern is to be able to move on in 
"{...}" as object-literal(-extension) syntax.
I was only imagine all reactions like "why they did not add ... there 
too - it's just logical?!" of future users... but it has its use (and 
compact minimal definotion) if it is to be used for and only for 
instance methods (constructor masking as a special one of them).

> If the alternative is *no* class syntax, you will have to do this
> anyway. Isn't this proposal still better than nothing?

Yes, reaction above.

>     Yes, we can go in little steps... but lots of them we already have
>     (super expressions are already planned to be orthogonal to classes),
>     and I think the next small step should be 'extends' for function
>     declarations (which, unless <|, explicitly says "I am creating
>     double chain here, in the spirit of 'classical' class inheritance;
>     and if thing after extends is not constructor, I throw").
>
>
> What would you rather have?
>
>      function Snake(name) extends Animal {
>          super(name);
>      }.prototype.{
>          move(){
>              alert("Slithering...");
>              super.move(5);
>          }
>      }
>
> or
>
>      class Snake extends Animal {
>          constructor(name){
>              super(name);
>          }
>
>          move(){
>              alert("Slithering...");
>              super.move(5);
>          }
>      }

It is not about rather, it is about having the former anyway, as base 
language construct, and having the latter also, building upon it... I 
can live without the latter, I think the more important (for the 
expressivity) is to have the former (which we have a special case of <|, 
but I do not like the special case there, and it is not there for 
function declarations, only for function expressions).

I heard a lot of voices that were telling something like "... and let us 
do X in a class construct" and I was always very uneasy. Whatever X is, 
it should be able to achieve "normally" in the language, not only 
thought class construct. Class construct should (I see it so) only 
integrate a pattern (but pattern that could live without it).

I don't know if I would write:

   class Foo extends Bar {
     constructor (x) { ... }
     method1 () {}
     method2 () {}
   }.prototype.{
     commonNum: 0,
     commonColl: []
   }

or

   function Foo (x) extends Bar {
     ...
   }.prototype.{
     method1 () {}
     method2 () {}
     commonNum: 0,
     commonColl: []
   }

> I know which one I would pick. At least as a safety syntax. The arguing
> can continue after that. I hope we get more than this minimum, but
> please, don't the indecision make the choice be "nothing".
>
> - Russ

Herby


More information about the es-discuss mailing list