This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: David Buck explains Java class objects Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Advertisement

There's been an interesting discussion of Java classes vs. Smalltalk classes - with a fair bit of misunderstanding all the way around - in comp.lang.java.advocacy. David Buck makes it all very clear:

I can see where Smalltalk people and Java people can get confused about classes and why Smalltalk people claim that classes in Java are somehow second class objects. Many of the Java people don't see the difference or the problem. Perhaps I could express it this way:

1) Java classes are objects If you call getClass() on a Java object, the thing you get back IS an object. It has the same status as any other object in Java. It allows polymorphism, dynamic binding, and all the other good things objects do. To say that it's not a real object is incorrect.

2)getClass() always returns an instance of Class

This is where Smalltalk and Java differ. In Java, getClass() returns an instance of Class. There are no subclasses of Class. In Smalltalk, the "class" method returns a subclass of Class - an object which not only contains information about the class but can also have methods associated to that class.

Suppose in Java you ask a String for its class. You'll get back in instance of Class with its instance variables filled in appropriately for String. The methods defined for this object are the same methods defined for every other Class object.

In Smalltalk, when you create a class, two objects are created - one we refer to as the class which holds information (including methods) of the instances of that class and another which we refer to as a metaclass which holds information (including methods) about the class.

The class is the sole instance of its metaclass.
'hello' class --> String String class -->

This means that you can define methods that 'hello' can understand in String (we call these instance methods) and you can define methods that String understands in (we call these class methods)

If String is a subclass of ArrayedCollection, then the String metaclass is a subclass of the ArrayedCollection metaclass. This means that class methods can be inherited.

3)static methods are NOT class methods

Since Java always uses instances of Class (not sole instances of a metaclass) and cannot support methods specific to particular classes of objects (class methods), it offers a different mechanism for doing a similar thing. The mechanism is called static methods.

Static methods are not ordinary methods. They do not support "this", they cannot be inherited, and they are not polymorphic. Smalltalkers tend to interpret these as class methods then complain that they don't work right. In fact, they are a completely different beast.

I hope this helps explain some of the differences in understanding.

Read: David Buck explains Java class objects