[EMAIL PROTECTED] wrote:
> I disagree with most of what you say here.
>
> Saying that Java Classes have classes is not
> the answer, what is the class of class? with out
> a meta layer writing things like serializers and
> integrated tools is much harder ( So does the fact
> that it is typed but that is a whole other religous
> war ).
The class of class is java.lang.Class. I can't write it clearer than this.
java.lang.Class was the first of a group of classes which form the meta layer for
Java, and are now collected in the Java Reflection API, package
java.lang.reflect. It allows you to find out absolutely everything about any descedant
of Object (every class you can write in Java). You can write
serializers, and integrated tools at will. Have a look at:
http://java.sun.com/products/jdk/1.2/docs/api/java/lang/reflect/package-summary.html
and find out what am I talking about.
Moreover, you don't need to write serializers in Java. Classes ObjectOutputStream and
ObjectInputStream (package java.io) already use the reflection API to
query object data and serialize it. You just need to tag your serializable classes
with the Serializable interface, allowing the referred streams to query the
class for data.
> It a conference someone in the audience asked one of the designers of Java to
>compare it to smalltalk. He said.
> "Java is like Smalltalk with a Straight jacket for
> protection"
>
I can't defend his comment. I have no idea what he meant by that, being that good or
bad. Quotations out of context can have very different meanings.
> you don't see a difference in elegance and readability between
>
> anInstance perform: #myMethod
>
> and
> anInstance.getClass().getMethod("aMethod",null).execute(anInstance, null);
>
I can't think of anything more object oriented than the structure presented by Java.
An instance is an instance *of* a class, a class *has* methods, a method
can be executed. This code is so elegant that I wrote it without referring to the docs
- I hope it's right :) -, just by using this knowledge about the API
structure (and the fact that a method's signature is it's name and parameter types).
The simplicity comes from the fact that, with the same technique, you can find what is
the return type for the method:
anInstance.getClass().getMethod("aMethod",null).getReturnType();
or which exceptions it may generate:
anInstance.getClass().getMethod("aMethod",null).getExceptionTypes();
etc, etc...
How do you do that in Smalltalk?
> Keep in mind that software needs to be read and maintained (and which is easier to
>learn?).
Humans respond better to structured data, than raw data. It is easier to remember that
a class has methods that can be invoked and queried, than to learn
there is a perform method in every class, a methodFields (?) method to find field
types, etc.
> And this is just a small example.
An example that proves nothing is useless.
> Using key words instead of having an extensible language does make the language more
>complicated.
It would, except that every programmer knows what for, if, while, switch mean. the
functionality vs complexity ratio is favorable to the adoption of these
keywords.
> There are good reasons why the best java development
> environment is written in Smalltalk.
Yes. VisualAge for Smalltalk is very similar, and was already on the market when the
VisualAge for Java project started. No company is more commited to Java
than IBM, and they've produced other very good tools with java. Check the alphaworks
site - http://www.alphaworks.ibm.com
VisualAge for Java contains Java code, and will increasingly be written in Java, just
because it's simpler to write a compiler/debugger for Java in Java.
> You think it is an exceptable solution to have two
> types of Integer, one that is primitive and one that isn't? This doesn't make
>systems harder to read and maintain?
As I mentioned, this is an almost reigious issue. There are undeniable performance
benefits. Also, mathematical formulas - a+b*c - are easier to read, than
a.add(b.multiply(c)). I don't think systems are harder to read and maintain because of
primitive types. There are a number of things you can't do with a
primitive type, but that is why Class types are there.
> Let me ask you something. Have you ever seen a study
> saying that programmers are more productive in Java
> than in Smalltalk? There is an interesting study comparing the two at
>http://www.lineaengineering.com/Resources/Productivity_/productivity_.html web site.
I said I am more productive with Java than with any other language I've used (and
there have been lots...). A great number of factors can influence the
productivity with a language, as well as popularity (JavaOne just beat the record of
attendants for a developer conference), and I haven't used popularity as
an argument.
> Simplicity is elagance.
Simple things I learn, I don't memorize.
--
Sergio Carvalho
---------------
[EMAIL PROTECTED]
If at first you don't succeed, skydiving is not for you
