Well you can use a hammer to plant a nail, and you can use it to kill your
neighbour.
Poor design has nothing to do with tools. If you don't want poor design,
don't hire poor designers. I used to work in a company where exceptions,
operators and multiple inheritance were strictly forbidden. I'm glad I left
that company, because with these tools I can largely improve my design.
I don't think I'm a poor designer or a developer. I know how
templates and operator overloading work, I just choose not to use
them because I know they can result in code that's difficult to
understand, to debug, and to modify, even if in the short term they
let you come up with (apparently) clever and elegant solutions to
certain problems. It's simply not worth the hassle in my opinion.
Since Java IS overloading operators (yes you can ADD strings), why are you
against operator overloading ?
A lot of people think that was a mistake, for precisely the reason
operator overloading in general is a mistake. It makes it too easy
for a user not to realise what's going on, ie. creating a new
StringBuffer and appending each time, with all sorts of obscure
performance implications (in the early days at least, it's more
efficient now).
Since casting IS necessary in pre 1.5 Java, because without casting, you
cannot access a Collection item, why are you against generics which provide
compile-time type checking and avoid casting ?
Because, although I avoid it when I can, I don't have any particular
problem with casting - it's 100% safe and predictable in Java. And
with relative few exceptions most uses of non-type safe collections
are *internal* to a class. For example, adding, removing or getting
(if that were relevant) a listener from an AWT or Swing component is
always via a typed interface such as ActionListener. The fact that it
isn't typed internally and there are casts in the one or two places
where the underlying collection is used really is not a big deal.
There are very unlikely to be errors in that code and it's the
external interface which is far and away more important. The
collection itself is part of the internal implementation and
shouldn't be exposed directly.
Did you switch from a large project with many developers to a small project
with a single developer ? That would be fresh air for anyone, I guess.
I switched from a team of about 8 C++ developers where I was
technical lead to a new Java project which grew from 4 developers to
over 50. That was in December 1996 and I've never looked back!
What I love in Java is not having to care about memory, and also being
always sure my exceptions are handled. This doesn't mean I should give-up on
some great tools I have in C++.
No argument about memory and exceptions, they are undoubtedly one of
the main productivity factors in Java's favour. Not so much how
they're handled though but the fact that runtime exceptions are
thrown automatically if you try to dereference a null pointer or go
past an array bounds. It's all about making code *predictable* in
advance; precisely what some of these features of C++ negate and why
I don't want them coming to Java.
-Rolf
--
Rolf Howarth, Square Box Systems Ltd, Stratford-upon-Avon UK.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
