Dynamic class default (was Re: Class method addition...)

Lars Hansen lhansen at adobe.com
Mon Apr 7 09:25:24 PDT 2008


Leaving AOP aside for the moment, ES4 has taken the 
following defaults from ActionScript:

  - a class Cls is open (can have arbitrary subclasses)
    by default; this is overridden by annotating
    Cls as "final".

  - a method M is virtual (can be overridden) by 
    default; this is overridden by annotating
    M as "final".

  - an instance of class Cls is sealed (cannot have
    dynamic properties) by default; this is overridden
    by annotating Cls as "dynamic".

  - a method or property of class Cls is in the
    package-internal namespace by default; this is
    overridden by annotating each method or property
    with an explicit namespace or by changing the
    default namespace with "use default namespace".

The alternative would be to have to annotate the class as
"open" if is not final; to annotate the method as "virtual"
or "overridable" if it is overridable; to annotate the
class as "sealed" if it cannot have dynamic properties;
and to have the methods and properties be public by default.

The AS defaults are probably correct for typical AS code
in the context of FlashPlayer or especially the Flex
framework.

But there is a mixture of constrained and unconstrained
defaults in our current choices, and I think it's useful
to question whether all the defaults are correct for ES4.
Waldemar has suggested that properties and methods should
be public by default; Kris is suggesting that classes
should not be dynamic by default (Alex Russell made the
same point some time ago).

Making classes dynamic by default is likely to make the
verifier -- what we previously called "strict mode" --
less effective, because a reference o.x cannot be flagged
as an error unless o is known to be an instance of a
sealed class that doesn't have an 'x'; if classes are
sealed by default then more errors will likely be caught
early.

(The verifier is not currently a part of ES4, and the
spec will not wait for it to be finished, but it is
valuable in some domains and having something normative in
ES4 would be a plus.  If the verifier becomes a reality
then Kris and Alex should expect that people who choose
to move to class-based development will seal their classes
to make the verifier more effective, so the net effect of
making classes dynamic by default may be smallish.  Who
can say?)

Anyhow, I'll be writing the spec for classes and interfaces
this week, so now is a good time to think about and discuss
these things.

--lars

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Kris Zyp
> Sent: 7. april 2008 08:53
> To: Brendan Eich
> Cc: es4-discuss Discuss
> Subject: Re: Dynamic class default (was Re: Class method addition...)
> 
> 
> > 'final' already means "can't be overridden" for methods and "can't
be 
> > extended by subclassing" for classes in several languages. Adding  
> > another meaning, even if it's of the same "mood", seems like a bad
> > idea to me.
> >
> > What's the point of your request? If you mean to promote "AOP"
> 
> I don't know what the connection would be.
> 
> > (a  sacred cow, per my last message to you, reply-less :-P)
> 
> I ran out of arguments :).
> 
> > , you risk  degrading overall integrity, or merely imposing 
> > a syntax tax as most  class users have to say "inextensible
> > class" (kidding, but it would  have some contextual keyword
> > in front -- and not "static").
> 
> Just a idea for budget cuts, it's rejection doesn't bother 
> me, not an important issue to me.
> Kris 
> 
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
> 



More information about the Es4-discuss mailing list