E
ender
Hi everyone.
Don't get me wrong there are many great reasons to program with Java
but there are also some things that I wonder about. And from what
I've heard the reasoning behind them involves abuse by other
programmers. I do not understand why Sun believes that by denying the
programmer powerful tools they are keeping us "safe". I realize that
many of these tools have been misused by programmers in other
languages but such misuse disadvantages the programmer and if they
don't know what they are doing they shouldn't be using those tools.
The three design decisions that bug me the most all revolve around
data structure. First is the lack of operator overloading. I have
seen many arguments for why operator overloading was not included
however to me operator overloading seems an important part of OOP.
The core of OOP is being able to make customized data types with built
in processing. With operator overloading the user defined types
become much more the primitive types they emulate and can represent
the real world better.
The second thing is that you should have more control over how objects
are passed. Although pass by reference is preferable in most cases
there are many instances when pass by value is required, having to
constantly use clone() is not a very efficient, or safe way. It would
be beneficial to have some form of data type. If a data type is added
however it should not follow the mistake of c# and restrict
inheritance as there are many times when data types should inherit.
The third and most important issue deals with consistency. There is a
huge gap between primitive types and user defined types where there
doesn't need to be. Operator overloading solves much of the problem
and user defined data types more so, but the fact is the primitive
types do not seem OO at all. They do not have any members and they do
not exhibit any polymorphism. They just stick out like a sore thumb.
Furthermore if user defined objects don't have object overloading then
primitive types shouldn't either, and especially not strings. Why
should you have to write fraction1.add(fraction2) for fractions but
not integer1.add(integer2)?
Some other features I would like, but are not quite as sever are
Multiple Inheritance, better support for properties, and some form of
function pointer.
In most cases no more than one class must be inherited from but in
some very specialized instances multiple inheritance is called for.
For example, a square is both a rectangle and a rhombus. However a
rhombus is not a rectangle and a rectangle is not a rhombus. The Java
solution would be to create rhombus and rectangle interfaces and apply
them to the square and to their corresponding rhombus and rectangle
classes. Unfortunately you do not always have access to the classes
you want to inherent. The biggest problem with multiple inheritance
is ambiguity. The best solution I can see is to require specific
implementations of overridden methods when names conflict and
optionally provide an implementation for the current class. (note:
this uses explicit inheritance as used by C#).
The last two are just slight annoences. There is no real need for
these feature other than convenience.
Don't get me wrong there are many great reasons to program with Java
but there are also some things that I wonder about. And from what
I've heard the reasoning behind them involves abuse by other
programmers. I do not understand why Sun believes that by denying the
programmer powerful tools they are keeping us "safe". I realize that
many of these tools have been misused by programmers in other
languages but such misuse disadvantages the programmer and if they
don't know what they are doing they shouldn't be using those tools.
The three design decisions that bug me the most all revolve around
data structure. First is the lack of operator overloading. I have
seen many arguments for why operator overloading was not included
however to me operator overloading seems an important part of OOP.
The core of OOP is being able to make customized data types with built
in processing. With operator overloading the user defined types
become much more the primitive types they emulate and can represent
the real world better.
The second thing is that you should have more control over how objects
are passed. Although pass by reference is preferable in most cases
there are many instances when pass by value is required, having to
constantly use clone() is not a very efficient, or safe way. It would
be beneficial to have some form of data type. If a data type is added
however it should not follow the mistake of c# and restrict
inheritance as there are many times when data types should inherit.
The third and most important issue deals with consistency. There is a
huge gap between primitive types and user defined types where there
doesn't need to be. Operator overloading solves much of the problem
and user defined data types more so, but the fact is the primitive
types do not seem OO at all. They do not have any members and they do
not exhibit any polymorphism. They just stick out like a sore thumb.
Furthermore if user defined objects don't have object overloading then
primitive types shouldn't either, and especially not strings. Why
should you have to write fraction1.add(fraction2) for fractions but
not integer1.add(integer2)?
Some other features I would like, but are not quite as sever are
Multiple Inheritance, better support for properties, and some form of
function pointer.
In most cases no more than one class must be inherited from but in
some very specialized instances multiple inheritance is called for.
For example, a square is both a rectangle and a rhombus. However a
rhombus is not a rectangle and a rectangle is not a rhombus. The Java
solution would be to create rhombus and rectangle interfaces and apply
them to the square and to their corresponding rhombus and rectangle
classes. Unfortunately you do not always have access to the classes
you want to inherent. The biggest problem with multiple inheritance
is ambiguity. The best solution I can see is to require specific
implementations of overridden methods when names conflict and
optionally provide an implementation for the current class. (note:
this uses explicit inheritance as used by C#).
The last two are just slight annoences. There is no real need for
these feature other than convenience.