Tired of 100s of stupid Getter/Setter methods

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

In that case what we have isn't of List of Airplanes, but an
AirplaneList which should have its own methods requiring Airplanes, and
perhaps some relevant methods for dealing with airplanes in the
aggregate (if applicable to the domain).

 

[Michael Borgwardt]

In that case what we have isn't of List of Airplanes, but an
AirplaneList which should have its own methods requiring Airplanes,

You've just described a typesafe container. Aren'you glad that they're
finally here with 1.5?

and
perhaps some relevant methods for dealing with airplanes in the
aggregate (if applicable to the domain).

class AirplaneList extends List<Airplane>
{
public void doSomethingWithThePlanes(){
...
}
...
}

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

You've just described a typesafe container. Aren'you glad that they're
finally here with 1.5?

Not really. Java has added more syntax for something easily implemented
with the language as it already existed.

<snip>


class AirplaneList extends List<Airplane>
{
public void doSomethingWithThePlanes(){
...
}
...
}

class AirplaneList {
private List airplanes;
....
add(Airplane anAirplane) { airplanes.add(anAirplane); }
....
}

 

[Michael Borgwardt]

Not really. Java has added more syntax for something easily implemented
with the language as it already existed.

Easily but tediously. Anything that forces you to write repetitive code
is bad and should be replaced with a generalized mechanism.

class AirplaneList {
private List airplanes;
...
add(Airplane anAirplane) { airplanes.add(anAirplane); }
...
}

Waste of time that could be spent on something important.

 

[Jezuch]

U¿ytkownik Michael Borgwardt napisa³:

Waste of time that could be spent on something important.

Besides, it's not a List anymore...
--
Ecce Jezuch
"Pale in the flare light the scared light cracks & disappears and leads
the scorched ones here; and everywhere no one cares the fire is spreading
and no one wants to speak about it
down in the hole Jesus tries to crack a smile beneath another shovel load"
- C. Cornell

 

[Mark 'Kamikaze' Hughes]

Doesn't someone inserting pigs into their airplane list have larger
problems than the (in)ability to insert the pig? Their problem is a
faulty algorithm, not the insert. How the heck did a pig end-up being
processed as an airplane?

Indeed. It's a stupid add-on for incompetent programmers who don't
test their code, have no idea what they're doing, and have
language-inappropriate expectations from C++. If you want to make sure
you don't put a Pig in a List of airplanes and have it fail at insertion
rather than extraction, use planelist.add((Airplane)o) instead of
planelist.add(o). It's that easy.

No real-world app designed by someone sane would have this problem to
start with.

 

[Mark 'Kamikaze' Hughes]

Yes, I could have done so. Since I wrote the original code years ago, I
don't recall my exact thought processes... but I probably just didn't
think about it. Nevertheless, I can emphatically claim that I would
have returned a read-only List if the interface had existed as a
superinterface of List.

You could always have implemented your own List type that did have a
read-only interface. Containers are a first-year student problem, not
rocket science.

 

[Dimitri Maziuk]

Mark 'Kamikaze' Hughes sez:
.... If you want to make sure

you don't put a Pig in a List of airplanes and have it fail at insertion
rather than extraction, use planelist.add((Airplane)o) instead of
planelist.add(o). It's that easy.

Like I said, only if you don't write class libraries. You seriously
expect every user of your planelist package to use that cast in add()?
Are you going to give them IQ tests programming exams before you let
them buy your code? Puhleeze.

Dima

 

[Chris Smith]

You could always have implemented your own List type that did have a
read-only interface. Containers are a first-year student problem, not
rocket science.

Ah, but I don't think that would have been a good choice. One gigantic
advantage of the java.util.List interface over any possible third-party
or in-house replacement is simply that it is standard. If I had
implemented my own interface instead of java.util.List, then I would
have required clients of the API to be familiar with a new list data
type that's not standard, to keep track of when one list type is used
versus the other and how to convert between them if needed, and
otherwise limited or obfuscated the usage of the API.

So yes, indeed using Collections.unmodifiableList (or some other way of
arranging for mutation methods to fail) would have been a good idea, and
I greatly wish for a standard read-only list interface, but replacing
the standard List interface with a non-standard alternative would be a
poor idea, I think for most such situations. The reason has nothing to
do with the difficulty of defining such an interface, and everything to
do with implicit advantages of using a well-known and widely published
interface for common abstractions such as data containers.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Indeed. It's a stupid add-on for incompetent programmers who don't
test their code, have no idea what they're doing, and have
language-inappropriate expectations from C++. If you want to make sure
you don't put a Pig in a List of airplanes and have it fail at insertion
rather than extraction, use planelist.add((Airplane)o) instead of
planelist.add(o). It's that easy.

No real-world app designed by someone sane would have this problem to
start with.

I think it's extremely limiting to look at the benefits of more precise
typing only in those terms. The point of encoding this information in
the language is to help avoid such misunderstandings as much as
possible. There are many ways this can happen. One example: when I am
working in Eclipse, hit ctrl-space, and see a method that returns a type
such as List<Airplane>, I know what I can do with the result of that
method. When I see a method that returns List, I have no idea. Yes, I
can certainly go read documentation and find out, but then I've spent an
extra couple minutes just to use one method. Then I go back and add a
cast for something the compiler could have known by itself... what a
chore!

It may have been true in the past that testing eliminated the need for
type information (though even then, the turn-around time for fixing a
bug in testing versus development is an order of magnitude higher), but
when most people are using development tools that use type information
to help with the development process itself, that's no longer the case.
Even if you insist those compiler error messages are not helpful, the
more intelligent editor help when writing code is still quite helpful.

Can we live without it? Of course! But wait a sec... you still haven't
actually said what's bad about the extra expressive power.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[=?ISO-8859-15?Q?Thomas_Gagn=E9?=]

I think it's extremely limiting to look at the benefits of more precise
typing only in those terms. The point of encoding this information in
the language is to help avoid such misunderstandings as much as
possible. There are many ways this can happen. One example: when I am
working in Eclipse, hit ctrl-space, and see a method that returns a type
such as List<Airplane>, I know what I can do with the result of that
method. When I see a method that returns List, I have no idea.

Why not name the method something revealing? Something that might
indicate its return value? No more complicated or imposing than naming
our variables so they communicate their purpose. All this can be done
without adding even-more-syntax to an already keyword-heavy and
increasingly complicated language.

 

[Chris Smith]

Why not name the method something revealing? Something that might
indicate its return value? No more complicated or imposing than naming
our variables so they communicate their purpose. All this can be done
without adding even-more-syntax to an already keyword-heavy and
increasingly complicated language.

Well, I'll be frank about this. I certainly believe in good choice of
identifiers, but when choosing an identifier is necessary to explain
something in the language domain like a return value, I look at that as
a stop-gap measure; something that needs to be done in order to work
around a flaw in the language.

Identifiers ought to be chosen within the context of the language-level
elements of an API, which should be presumed known. Imagine if the
identifier were used as an excuse to avoid a lot of other obvious
interface elements, and I had to declare a method called: (quoting to
prevent my news software from wrapping...)

getPropertiesFromSectionNameAsStringReturningMapOfPropertyNameAsStringToValueAsObjectPossibleThrowingIOException

Wow, that's a handful!

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Mark 'Kamikaze' Hughes]

I think it's extremely limiting to look at the benefits of more precise
typing only in those terms. The point of encoding this information in
the language is to help avoid such misunderstandings as much as
possible. There are many ways this can happen.

So, seeing as you're now scratching for even more marginal cases to
support it, you do at last recognize that encoding the type information
in the container is not necessary for actual use?

One example: when I am
working in Eclipse, hit ctrl-space, and see a method that returns a type
such as List<Airplane>, I know what I can do with the result of that
method. When I see a method that returns List, I have no idea. Yes, I
can certainly go read documentation and find out, but then I've spent an
extra couple minutes just to use one method.

I must be misreading something, because I cannot believe you just said
that. It looks like you're suggesting using methods that you don't
understand, just looking through the signatures and picking one at
random that looks like it might fit your needs, rather than actually
reading the documentation that the library developer wrote. You might
get Shakespeare's plays with that method and enough time, but I'm
guessing it won't be on schedule.

Then I go back and add a
cast for something the compiler could have known by itself... what a
chore!
It may have been true in the past that testing eliminated the need for
type information (though even then, the turn-around time for fixing a
bug in testing versus development is an order of magnitude higher), but

You're talking about the obsolete (though still widely practiced)
practice of testing only when the product is ready to ship, if then, and
then making sweeping changes to fix bugs you randomly discover in
testing. I'm talking about writing unit tests as you code, preferably
*before* you implement anything, so you never have broken code to begin
with, because you immediately see a red test bar or failure report when
the tests run after every compile. See

when most people are using development tools that use type information
to help with the development process itself, that's no longer the case.
Even if you insist those compiler error messages are not helpful, the
more intelligent editor help when writing code is still quite helpful.
Can we live without it? Of course! But wait a sec... you still haven't
actually said what's bad about the extra expressive power.

It's a waste of time and resources to write, it bloats up programs, it
adds more complexity and syntax to a language that's already borderline
unreadable gibberish, and it's wasted the time of Sun engineers who have
been ignoring real bugs in favor of some syntactic sugar.

 

[Chris Smith]

So, seeing as you're now scratching for even more marginal cases to
support it, you do at last recognize that encoding the type information
in the container is not necessary for actual use?

You may be confusing me with someone else. I've never said that such
type information is necessary for actual use. I do think it's helpful,
though.

I must be misreading something, because I cannot believe you just said
that. It looks like you're suggesting using methods that you don't
understand, just looking through the signatures and picking one at
random that looks like it might fit your needs, rather than actually
reading the documentation that the library developer wrote.

It's unfortunate that things aren't that black and white, isn't it?
Otherwise, you and I could both be geniuses.

I'm not of course actually talking about using a method that I don't
understand. I'm talking about whether I have to look at the
documentation in order to understand a method. You're taking it for
granted that I do; in practice, it depends on the situation. I have a
lot of sources of that kind of information without even glancing at
formal documentation. One such hint is the method name; another is the
formal parameter list and return type; another is the contextual role of
the object that I'm using. Between all these hints, I can figure out
the more obvious uses of an object without much effort, and can refer to
the documentation when there's a fringe that isn't entirely covered by
context and naming.

Going even further, there are factors here that definitely affect the
ability to become familiar with an API. If the immediately visible
information about an API element is incomplete, then I have to memorize
that information before I can use the API effectively. And no, I don't
consider referring to the API docs before coding every method invocation
an "effective" use of the API.

You're talking about the obsolete (though still widely practiced)
practice of testing only when the product is ready to ship, if then, and
then making sweeping changes to fix bugs you randomly discover in
testing.

I am? That's news to me, and I'm the one who was talking about it! I
must be losing it. Either that, or I'd appreciate your not making
assumptions about what I'm saying.

Given the choice between finding out about a bug as I'm writing the
code, or waiting even 15 minutes to next run my test suite, I'd rather
find out as I'm writing the code (that is, within 10 seconds or so).
That can prevent me from spending the next 30 minutes working on a false
assumption. If nothing else, it lets me fix a bug when I'm working
specifically with that couple lines of code, not return to it after I've
moved on. Sure, testing every 30 minutes is better than testing every
night or every major release, but you're not going to be able to run
unit tests every few seconds. (For one thing, the unit tests on my
current project take about three minutes to complete, so running them
every 10 seconds would be a losing proposition.)

It's a waste of time and resources to write, it bloats up programs, it
adds more complexity and syntax to a language that's already borderline
unreadable gibberish, and it's wasted the time of Sun engineers who have
been ignoring real bugs in favor of some syntactic sugar.

I'm curious: borderline unreadable gibberish? That's an odd thing to
say about a language that's one of the more readable that I work in.
Sounds like you've got a problem with the language itself, not just this
feature.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[=?ISO-8859-15?Q?Thomas_Gagn=E9?=]

I'm curious: borderline unreadable gibberish? That's an odd thing to
say about a language that's one of the more readable that I work in.
Sounds like you've got a problem with the language itself, not just this
feature.

Normally, I would let Mark answer for himself, as he probably will, but
from the standpoint of someone who has taught Java I have to agree with
him. Java has wandered far from the conceptual simplicity of the
languages that preceded it (except perhaps, C++) and its many keywords
and inconsistancies can make it look like a lot of gibberish--even to
those familiar with programming. The number and size of books on Java
programming are a fairly decent indicator of its complexity--and
complexity is not necessarily proportional to functionality.

 

[Chris Smith]

Normally, I would let Mark answer for himself, as he probably will, but
from the standpoint of someone who has taught Java I have to agree with
him. Java has wandered far from the conceptual simplicity of the
languages that preceded it (except perhaps, C++) and its many keywords
and inconsistancies can make it look like a lot of gibberish--even to
those familiar with programming. The number and size of books on Java
programming are a fairly decent indicator of its complexity--and
complexity is not necessarily proportional to functionality.

Right. Since my experience is quite the opposite, I'd like to hear
*why* people think that. Perhaps we're merely thinking on different
wavelengths here, but you've got my interest up.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Adam Jenkins]

The number and size of books on Java
programming are a fairly decent indicator of its complexity--and
complexity is not necessarily proportional to functionality.

That's a somewhat disingenuous observation. I think you'll find that
most of those books are about APIs, architectures, and other general
programming topics, not about the language itself, and as such they
simply reflect the popularity of the language rather than its
complexity. While there are simpler programming languages than Java, I
think the syntax and semantics of the Java language are relatively
simple compared to other OO languages.

 

[Dimitri Maziuk]

Chris Smith sez:

Right. Since my experience is quite the opposite, I'd like to hear
*why* people think that. Perhaps we're merely thinking on different
wavelengths here, but you've got my interest up.

Actually, I'd side with you as I have to deal with Perl
and C++ as well as Java: Java is way more readable than
many other languages.

However, it has:
Inconsistent method names: size() vs. length(), for example.
The whole deal with immutable objects: wrapper classes vs.
primitive types, String vs. StringBuffer. And when you dig
deeper into string interning, you start thinking that maybe
null-terminated character arrays aren't such a bad idea in
comparison.
And the list goes on.

Dima

 

[Chris Uppal]

Actually, I'd side with you as I have to deal with Perl
and C++ as well as Java: Java is way more readable than
many other languages.

If you are dealing regularly with C++ or Perl, then it's no surprise that you
find Java easy. I remember when I started Java, I'd been doing C++ for a few
years before-hand and Java was a wonderful breath of fresh air -- sort of like
going back to C again, but without the loss of expressivity. And as for Perl!!
<shudder/>

But then it *does* depend on what you are used to. These days I spend most
time in Smalltalk, and the boot's on the other foot. By comparison, Java now
feels clunky, wordy, obfuscated, repetitive, and inexpressive. (I still like
Java, though, or I wouldn't be posting here). I think that Thomas (who stated
this sub-thread) is also a Smalltalker, which would explain some of his lack of
enthusiasm for the Java syntax too.

However, it has: [....]
And the list goes on.

The syntax that *particularly* gripes me is the anonymous inner class thing --
for one thing there's no way to lay them out happily. Worse, I've never yet
seen an example (in any layout) where my eyes realised that they were looking
at a class declaration without prompting from what passes for my intellect.
Gross.

But I must admit that most of the things that bother me about Java these days
are semantic rather than syntactic. It's a shame but as Java grows and
develops, I'm finding more and more that the JVM has cleaner, simpler, and more
workable semantics (admittedly, nobody would want to write bytecodes by hand,
but you could call that a mere syntactic issue) than the increasingly cluttered
camel of a language that is balanced over it...

-- chris

 

[Tom McGlynn]

You may be confusing me with someone else. I've never said that such
type information is necessary for actual use. I do think it's helpful,
though.




It's unfortunate that things aren't that black and white, isn't it?
Otherwise, you and I could both be geniuses.

I'm not of course actually talking about using a method that I don't
understand. I'm talking about whether I have to look at the
documentation in order to understand a method. You're taking it for
granted that I do; in practice, it depends on the situation. I have a
lot of sources of that kind of information without even glancing at
formal documentation. One such hint is the method name; another is the
formal parameter list and return type; another is the contextual role of
the object that I'm using. Between all these hints, I can figure out
the more obvious uses of an object without much effort, and can refer to
the documentation when there's a fringe that isn't entirely covered by
context and naming.

Going even further, there are factors here that definitely affect the
ability to become familiar with an API. If the immediately visible
information about an API element is incomplete, then I have to memorize
that information before I can use the API effectively. And no, I don't
consider referring to the API docs before coding every method invocation
an "effective" use of the API.




I am? That's news to me, and I'm the one who was talking about it! I
must be losing it. Either that, or I'd appreciate your not making
assumptions about what I'm saying.

Given the choice between finding out about a bug as I'm writing the
code, or waiting even 15 minutes to next run my test suite, I'd rather
find out as I'm writing the code (that is, within 10 seconds or so).
That can prevent me from spending the next 30 minutes working on a false
assumption. If nothing else, it lets me fix a bug when I'm working
specifically with that couple lines of code, not return to it after I've
moved on. Sure, testing every 30 minutes is better than testing every
night or every major release, but you're not going to be able to run
unit tests every few seconds. (For one thing, the unit tests on my
current project take about three minutes to complete, so running them
every 10 seconds would be a losing proposition.)




I'm curious: borderline unreadable gibberish? That's an odd thing to
say about a language that's one of the more readable that I work in.
Sounds like you've got a problem with the language itself, not just this
feature.

This probably isn't what the poster had in mind, but one of my
issues with Java is that while it often makes hard things easy, sometmes
it makes easy things hard. E.g., consider a case of a very
simple program where I just want to add two numbers from standard input
and print out the result... In Fortran we might have:

program adder
real a,b
read (fmt=*,unit=*) a,b
write(fmt=*,unit=*) a+b
end

or just

real a,b
read *,a,b
print *,a+b
end

In C this program becomes something like:

main (int argc, char *argv[]) {
float a,b;
scanf("%f %f", &a, &b);
printf("%f\n", a+b);
}

It's a bit less clear, but the basic read the input, write the result logic is
still apparent.

Let's look at this in Java...

public class Adder {

public static void main(String[] args) throws Exception {

// Use BufferedReader and StringTokenizer since
// StreamTokenizer can't handle exponents (e.g., 5.3E-6)

java.io.BufferedReader br = new java.io.BufferedReader(
new java.io.InputStreamReader(System.in));
String line = br.readLine();

java.util.StringTokenizer st = new java.util.StringTokenizer(line);

double v1 = Double.parseDouble(st.nextToken());
double v2 = Double.parseDouble(st.nextToken());

System.out.println(v1+v2);
}
}

Looking at this doesn't give me any sense of what's going on. I have to
analyze this in detail to see what's happening. It's not only harder
to write, it's much harder to understand.


Sometimes Java makes me feel like I have to scratch my fingernails
against the blackboard to get something done... Not only do
you have to go to great lengths just to get something conceptually
very simple done, there are often little gotcha's (such as
the one alluded to in the comment) that you have to be aware
of. Of course I rarely write programs that do this little -- but
I do run into problems like this fairly frequently in the context of
larger programs.

Regards,
Tom McGlynn