Agreed

Hmm... it is another valid use - but certainly not one I'd favour
usually - I think I've only ever seen one instance where it was the
right choice - though for the life of me I can't remember it :-)

That's Delegation though, not inheritance.

In the Implementation Inheritance we could have code like:

class OtherClass {
  String getName() { return "foo"; }
}

public class MyClass {

 private OtherClass myOtherClassPart = new OtherClass();

 public String toString() {
   return getName(); // <-- call to non-existent method
 }

}

When in fact with current Java, this would not compile because MyClass
does not have a method called 'getName()'. So we have to do:

 public String toString() {
   // we have to delegate to member var.
   return myOtherClassPart.getName();
 }

isamura schreef:

Why didn't you test?  Of course it won't compile.

Well, I suggest a bit of both.

One the one hand, Java's classes are nothing like Smalltalk classes.  In Java a
class is not an object, it is only a language construct.  So many of the things
that you would naturally use a class object for in Smalltalk just don't make
sense in Java.  E.g. you can't use a class as a factory object -- if you
need/want to use that pattern then you have to code up all the necessary stuff
yourself.  As a result, all the "static" stuff has a semantics that will seem
unfamiliar to a Smalltalker -- "static" is not equivalent to Smalltalk's "class
side".

On the other hand, within fairly wide limits, Java's static members are used in
just the same way as Smalltalk's class-side method and classvars / class
instvars.  Most, probably all, of the reasons for putting code on the class
side in Java would be equally valid in Smalltalk (the reverse is not always
true, since Java classes are not objects).  So, more often than not, the
thinking is exactly the same.  In fact I like to "pretend" that Java's classes
/are/ objects (distinct from their instances) when I'm deciding where to put
code -- decide which "object" is responsible for <whatever> and put the code on
the appropriate side of the fence.

Put it like this: it's perfectly reasonable to say that "static methods are
analogous to class methods", /provided/ that you hear in mind that the analogy
is rather loose and incomplete.

   -- chris

correct

Hm, I see. But doesn't the fact that you would have to manually change
'Dog' to 'Chihuahua' point to a design quirk: That you shouldn't use a
static method but an instance method that can be inherited (and
overwritten)?
So, I'm sorry that myObject.staticMethod() still doesn't make sense to me...

Another question: If the compiler replaces
ClassB.staticDefinedInClassA() by ClassA.staticDefinedInClassA() what is
the point in not inheriting static methods through subclasses??? If you
don't inherit, you can write ClassB.staticDefinedInClassA() but you
won't get the method via reflection of ClassB since
ClassB.class.getMethods() won't return it and
ClassB.class.getDeclaredMethods() neither. You save the method lookup
for static methods, ok, but is there somethings else I'm missing?