Re: problems with Java

ender <astrothayne@xxxxxxxxx> wrote:
I do not understand why Sun believes that by denying the
programmer powerful tools they are keeping us "safe".

Then you've never had to support someone else's code, I suspect. There is not
a direct correspondence between power and abusability, and I fully support
leaving out features that are
1) abused more often than not
2) not a hardship to do without
In almost all cases, features left out of Java have more easily-understood
idioms to get the job done.

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.

I agree with you here. A _LIMITED_ form of operator overloading would make
the language clearer. Something like hardcoded operators, such that
Object has an implementation of
Object operator(Operator, Object)
And operators are just shorthand for calling this method. Override at will.

Simply having == call equals() and a DIFFERENT method for
object identity would save a ton of bugs.

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.

Here I disagree. Making the Clone() explicit is a fine workaround, and makes
the programmer know what's happening.

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.

I'm unclear what this means. How is a data type different from a final
immutable object?

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.

I don't think anyone disagrees here.

Some other features I would like, but are not quite as sever are
Multiple Inheritance

I'm torn on this. There's a LOT of complexity for not very much power, but
it's a power there's no good workaround for.

better support for properties

Fully agree.

and some form of function pointer.

Disagree. Better syntax for anonymous inner classes, sure. Pure function
pointers aren't needed.
--
Mark Rafn dagon@xxxxxxxxx <http://www.dagon.net/>
.

Relevant Pages

  • Re: C++ has Boost libraries, C?
    ... How can a language without objects support operator overloading? ... For reference, what you've done here is create an object. ... The point is that C does support the creation of objects. ... What it doesn't support is operator overloading, ...
    (comp.lang.c)
  • Re: The strengths of FORTH
    ... The issue is vocabulary bloat and user confusion. ... Instead of type checking and operator overloading the Forth syntax has ... So Forth is closer to natural languages here than to mathematics. ... No big issue, but to me, the Forth way to express data types is the ...
    (comp.lang.forth)
  • Re: C++ has Boost libraries, C?
    ... For reference, what you've done here is create an object. ... the language remains ... The point is that C does support the creation of objects. ... What it doesn't support is operator overloading, ...
    (comp.lang.c)
  • Re: The Decline of C/C++, the rise of X
    ... > would drastically reduce the abuse of operator overloading. ... > Complex and type String because String does not support division. ... With some extensions like Multi Parameter Type Classes and Functional ... bad upfront design and allows you to add your own overloaded functions ...
    (comp.programming)
  • Re: Fastcode [Social] Just feeling lonely ;-)
    ... and get us reference counting support from the compiler earlier? ... Or is it one of the cases operator overloading in D2006 won't support? ... The binary format would be quite close to that of a true reference-counted UnicodeString, getting clean casting & operator support from the compiler being the issue (not such an issue for AnsiStringUnicodeString, implicit casting not being such a good idea ...
    (borland.public.delphi.language.basm)