Re: Tired of 100s of stupid Getter/Setter methods

From: Tom McGlynn (tam_at_lheapop.gsfc.nasa.gov)
Date: 01/15/04 

Date: Thu, 15 Jan 2004 16:14:25 -0500

Chris Smith wrote:

> Mark 'Kamikaze' Hughes wrote:
>
>> 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.
>
>
>>>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 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.
>

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

Relevant Pages

  • Re: Bluetooth application development
    ... It's a VERY complex API, maybe the most-complex that I've seen for Windows. ... Why MSDN is not providing enough documentation to develop application from ... I don't see any way to truely automate pairing; ... Here also i have to start the pairing process then Headset profile ...
    (microsoft.public.windowsce.app.development)
  • Re: NullPointerException
    ... I would rather write APIs that actually allow the API user to make that ... they are bugs waiting to happen. ... should be a checked or unchecked exception. ...
    (comp.lang.java.programmer)
  • Re: Are things getting difficult?
    ... any files have been added since we last saw that card, ... I'm faced with a lot of documentation that waffles on endlessly about ... resource is, or what the syntax is for describing one. ... To me that's an admission that the API is badly designed. ...
    (uk.comp.os.linux)
  • Re: Tired of 100s of stupid Getter/Setter methods
    ... > reading the documentation that the library developer wrote. ... ability to become familiar with an API. ... Given the choice between finding out about a bug as I'm writing the ... say about a language that's one of the more readable that I work in. ...
    (comp.lang.java.programmer)
  • Re: Basic x86 instructions?
    ... > If you have second level documentation about the x86 architecture ... a good asm-based introduction to the WIN32 API. ... >> linux syscalls, dos interrupts, or WIN32 API). ...
    (alt.lang.asm)