[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-general
Subject:    RE: Future JDK features: Class Instance Variables (a la Smalltalk)
From:       "Gary Gregory" <ggregory () seagullsoftware ! com>
Date:       2004-10-26 0:02:58
Message-ID: 2B64219028BBFF48B3CC957EF10B58FE3093F4 () ns1018 ! SSSI ! seagull ! nl
[Download RAW message or body]

IMO, the class instance variables concept is a great feature that one
does not need everyday; but, when you do run into a use-case in Java, it
hurts. 
I'll present the top two classic examples that I've run into countless
times:

(1) The GUI Node subclasses.

o You need to populate a GUI list or a tree where each item is
represented in the view in some fancy manner: icons, fonts colors, bells
and whistles. 

o You create an abstract super class, like a UiTreeNode, with a
subclasses for each kind of domain object you care to represent:
FileTreeNode, DirectoryTreeNode, CustomerTreeNode, ZingBatTreeNode, etc.


o You decide that for your application, some attributes like font and
color can change for each instance of UITreeNode but that each subclass
needs only one icon and one bell.

o You create a font and color instance variable in UITreeNode. 

o But what do you do for the icon (and bell)? You cannot create a 'class
instance variable' in Java. What you'd want is a static variable defined
in UITreeNode whose value is unique for each subclass. You have two
choices: 

(a) You make the icon (or whatever resource) an instance variable, which
uses more memory (not that big a deal IMO unless you have huge lists)
and incorrectly lets the reader believe that it is OK for each instance
to have a different icon. 

This is not good because your code does not reflect your design. You are
forced to very carefully Javadoc things or add code to make sure rules
are not broken. 

In this case you can share the code in the super class like the
accessor, the mutator and some management methods. By definition, you
are not sharing the instance variable between instances obviously.

(b) You can do it the other way, which is, you *duplicate* code in each
subclass. You duplicate the static variable definition and the code. So,
here, you share nothing and as we'll all agree, code duplication should
be avoided.

The third solution that I am only listing for completeness is to use
some abstract methods in the root class, which ends up being a mixture
of (a) and (b) and is even more confusion and hard to grok, IMO. 

The Class Instance Variable solves all of these problems. 

(2) Logging with subclasses

A Class Instance Variable is nice when you want to have one log category
per subclass in a hierarchy. 

Gary

> -----Original Message-----
> From: Dain Sundstrom [mailto:dsundstrom@gluecode.com]
> Sent: Monday, October 25, 2004 15:21
> To: Jakarta General List
> Subject: Re: Future JDK features: Class Instance Variables (a la
> Smalltalk)
> 
> Can you explain what this is and why it is more useful then annoying?
> IMHO, most of the new features in Java 5 are way more annoying then
> useful.
> 
> -dain
> 
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
> 
> On Oct 25, 2004, at 2:42 PM, Gary Gregory wrote:
> 
> > Future JDK features: Class Instance Variables (a la Smalltalk).
> >
> > Gary
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]