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

From: Chris Smith (cdsmith_at_twu.net)
Date: 01/14/04 

Date: Wed, 14 Jan 2004 10:03:13 -0700

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. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Relevant Pages

  • Re: CRT and Win32 SDK
    ... However, it might give a reader an impression that when doing embedded programming one typically has a full-fledged language at hand, where in effect the runtime library implements what the OS would provide on e.g. a PC. ... The C and C++ standards differentiate between hosted and free-standing implementation to deal with the special constraints of embedded programming, where free-standing doesn't need to provide all of the language's standard library, but even that distinction does in practice not go far enough: it might be that fundamental language features such as static variables and exceptions are not available on the embedded platform's language implementation. ... Both the user-mode Win32 API and the kernel ... The documentation remarks are very important parts of that documentation and form the main part of it. ...
    (microsoft.public.vc.language)
  • MSP 2000/2002/2003 VBA API Bug - View and Table switching
    ... Bug #1 - API parameter values are language specific ... There seems to be a serious limitation in all MSP versions that prohibits ... The problem is that MSP API requires English strings such as "Gantt ... Bug #2 - Application.EditTable and other methods in this category require ...
    (microsoft.public.project.vba)
  • Re: Who are the maintainers of basic commands ?
    ... ]> people here agree that it is indeed a bug, ... ]LANGUAGE environment variable also plays a role, ... only the first language is taken into ... but defects in documentation are pretty low on the ladder ...
    (comp.os.linux.misc)
  • Weekly Python Patch/Bug Summary
    ... Patch / Bug Summary ... Help with Python codebase ... Update to Macintosh library documentation ... Segfaults on memory error ...
    (comp.lang.python)
  • Re: Tired of 100s of stupid Getter/Setter methods
    ... seeing as you're now scratching for even more marginal cases to ... >>reading the documentation that the library developer wrote. ... > ability to become familiar with an API. ... >>been ignoring real bugs in favor of some syntactic sugar. ...
    (comp.lang.java.programmer)