inheriting statics

[Jeff Dyer]

Having base class statics in scope can actually make your code less
fragile. Classes are factories that create related instances. Those
related instances might get initialized using related values. Access to
base class statics makes relating such values more convenient.

Also, the obscurity I wrote about relates to the meaning of 'extends'.
Should 'extends' mean copy all the names of all the statics in all the
base classes into my derived class object? And if it does, what do those
inherited names mean (add a new property, alias a shared property,...)?
We've decided to keep it simple and have 'extends' mean something only
to instance objects, not class objects. I think Java should have done
the same.

Jd

> -----Original Message-----
> From: P T Withington [mailto:ptw at pobox.com]
> Sent: Monday, April 23, 2007 1:22 PM
> To: Jeff Dyer
> Cc: Peter Hall; Dave Herman; Neil Mix; Brendan Eich; Nicolas Cannasse;
> es4-discuss at mozilla.org
> Subject: Re: inheriting statics
> 
> [Picking up on this ancient thread...]
> 
> If that is the argument against inheritance, why have the class
> statics of all your superclasses be 'in scope'?  Doesn't that lead to
> similar obscurity?  Doesn't it make for fragile code?
> 
> On 2007-01-09, at 12:55 EST, Jeff Dyer wrote:
> 
> > The argument against inheriting statics is one for simplicity. A
class
> > defines a factory and the type of instances created by that
> > factory. The
> > class objects (the factories, not the instances) of different
classes
> > have unrelated types and purposes, even if the instance types they
> > introduce are subtypes. Class statics are a simple convenience for
> > sharing state that is somehow associated with the meaning of a
> > particular class. Aliasing them through other class objects could
lead
> > to annoying name conflicts and obscure their otherwise clear
meaning.
> >
> > Jd
> [...]