Finding a "safety syntax" for classes

Russell Leggett russell.leggett at gmail.com
Wed Mar 21 06:25:42 PDT 2012


On Wed, Mar 21, 2012 at 7:03 AM, Herby Vojčík <herby at mailbox.sk> wrote:

> Allen Wirfs-Brock wrote:
>
>> We can live quite nicely with treating class declaration like const
>> declarations. The name is logically hoisted so it is visible over the
>> lexical scope, but the name is temporally dead until the class
>> declaration is executed, in statement sequence, as an initializer. That
>> means that we can have circular references between classes and forward
>> references in inner functions to classes. The class declaration just
>> need to be initialized before any such reference is actually evaluated.
>> Its TDZ for classes.
>>
>
> +1 (I wrote similar thing)
>
>  ...
>>
>>
>> So here is my one possibly future hostile (or we need to decide now)
>> issue:
>>
>> class A {};
>> A.classProperty="A";
>> class B extends A {};
>> Console.log(B.classProperty); //"A" or undefined??
>>
>> I don't believe Russell said, one way or the other. Potentially either
>>
> He said "A" in answer to my post (where I assumed he means "A", I think it
> should be "A"):
>
>> [about Russell's proposal]: I silently assume here that extends
>>>
>>> creates, of course, double chain (constuctor inherits as well as
>>> prototype inherits, not just the latter)
>>>
>>
>> Correct
>>
>
Yeah - that is the way I was leaning, partly because I like it, and partly
because that was the behavior in <| for functions in the class pattern. I
think it could help make it easier for people to fill the gaps in the
minimal syntax. For example, many class libs have some mixin functionality.
If mixin were added to a custom base class, then you could do:

    class Foo extends MyBase {
        ...
    }.mixin(enumerable);

Thats not the only way to get the job done, so its not really critical. I
think Mark's concerns are valid about using "this" at the class level to
take advantage of the static inheritance, but ultimately I think its a
useful tool. If people don't use it, I don't think it will really add much
cognitive load. On the other hand, I think allowing it will really let
JavaScript shine as a prototype language. Statics in other languages like
Java are frowned upon (in some circles) precisely because they aren't very
Object Oriented. You can't inherit or override them like you can instance
methods. I think this would be advantage JS. In the spirit of *safety
syntax* though, I personally could go either way. I think its nice, but not
critical, and shouldn't derail classes.



>
>  way could be seen as future hostile if you think the "right" answer is
>> the other one (and we have to do something in this regard). Personally I
>> think the answer should be "A" which implies that we have class-side
>> inheritance. This is a departure from current practice but because
>> "classes are functions" there is no way in ES<=5.1 to set up class side
>> inheritance other than by mutating __proto__.
>>
>> We could make an accommodation that this only occurs if the "superclass"
>> object is a function. Otherwise, the "superclass" is only uses as the
>> [[Prototype]] of the prototype and the constructor function simply
>> inherits from Function prototype. BTW, I assume the thing the the right
>> of extends is an expression.
>>
>> So, if you could say:
>> class B extends A.prototype {}
>>
>
> Please, rather different syntax (or nothing) then different behaviour
> based on context.
> After all, this is the less usual case, and can be achieved by:
>
> let B = A.prototype <| function () {
>  ...
> }.prototype.{
>  ...
>
> }
>

Yeah, this was not an assumption I had been making. I had, in fact, been
thinking the opposite. To the right of extends would always be a
constructor function. Being more restrictive on it now should not be future
hostile, and is less controversial.

- Russ


>
>  if you don't want the class-side inheritance
>>
>> To wrap up, this look really promising if we can restrict the feature
>> scope in the manner Russell suggests. Hey, I could knock this off and
>> have it in the spec. draft in a couple days work. There just isn't that
>> much to it.
>>
>> Allen
>>
>
> Herby
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120321/2b8d439a/attachment.html>


More information about the es-discuss mailing list