Constructor inheritance

[Chris Uppal]

Perhaps I should drop the notion that static methods are analogous to
class methods. And that class methods don't exist in Java. Do correct me
if I am mistaken.

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

 

[Roedy Green]

When a new
object is created, the JVM first allocates its memory, setting all values to
their defaults, and then invokes the constructor "method" on that object, that
means that the code has a valid "this" when it runs.

by defaults I presume you mean 0 rather than the

int q = 7;

value.

 

[Andrew McDonagh]

by defaults I presume you mean 0 rather than the

int q = 7;

value.

correct

 

[isamura]

...
: isamura wrote:
:
: > Perhaps I should drop the notion that static methods are analogous to
: > class methods. And that class methods don't exist in Java. Do correct me
: > if I am mistaken.
:
: 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".
:
This does explain why it is not possible to assign the actual "class" to a variable and use it else
where to declare the type of variables and instances. For example,

Class c = ClassA;
.....
c cInstance = new c();
....

is unsupported.

: 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.
:
Agreed. I am finding that I can't simply "map" Smalltalk concepts to Java without (in specific
cases) working around limitations/restrictions. It can be frustrating but is a good learning
experience in any case.

..K

 

[Chris Uppal]

isamura wrote:

[me:]

Agreed. I am finding that I can't simply "map" Smalltalk concepts to Java
without (in specific cases) working around limitations/restrictions. It
can be frustrating but is a good learning experience in any case.

Sympathy ;-)

Same with learning any new language, the sooner you can stop thinking in OLD
while programming in NEW the easier it'll be and the less mess you'll create.

(I remember getting into something of a mess programming in C++ but thinking in
Java. I had known C++ for years, but had just started in Java and was very
enthusiastic about its way of doing things. Fortunately I had not yet
discovered Smalltalk at the time, or I would probably have created total havoc
;-)

-- chris

 

[Roedy Green]

Agreed. I am finding that I can't simply "map" Smalltalk concepts to Java without (in specific
cases) working around limitations/restrictions. It can be frustrating but is a good learning
experience in any case.

The tendency is to try to figure out how you can get the same effect
you are used to in the new language. This will drive you nuts since it
will be absurdly clumsy. What you have to do is look for code that
tackles the same sort of problems you want to solve and see which
tools they are using.

At the very least, make sure you understand the tools that everyone
seems to be talking about a lot.

These are the starting toolkit.

My problem with Java was coming from a MASM, FORTH, Abundance, C++
background, I tend to think in very low level terms what I want to
accomplish. To me the language was just a sort of shorthand for
getting the effects I wanted. But in Java the low levels simply are
not accessible at all and nobody ever talks about how things are
implemented. I had no model to hang my understanding of Java on
without that.

Often I felt like a monkey in cage reaching for bananas just out of
my reach when all I wanted the fool thing to do was generate some
sequence of three machine instructions.

 

[isamura]

...
: On Sun, 30 Oct 2005 16:50:35 -0500, "isamura" <[email protected]>
: wrote, quoted or indirectly quoted someone who said :
:
: >Agreed. I am finding that I can't simply "map" Smalltalk concepts to Java without (in specific
: >cases) working around limitations/restrictions. It can be frustrating but is a good learning
: >experience in any case.
:
: The tendency is to try to figure out how you can get the same effect
: you are used to in the new language. This will drive you nuts since it
: will be absurdly clumsy. What you have to do is look for code that
: tackles the same sort of problems you want to solve and see which
: tools they are using.
:
Both you and Chris U. made good points. I am glad to hear others have had similar experience.

..K