Re: Java Code Convention Guidelines question...

From: rkm (rkm_at_invalid.com)
Date: 01/09/04 

Date: Fri, 09 Jan 2004 02:43:37 -0700

Chris Smith wrote:
> rkm wrote:
>
>>>That's not the issue. The issue is invoking a static method while
>>>thinking that it is (and therefore expecting it to act like) an instance
>>>method. Since the two behave in completely different ways, this could
>>>add bugs to code very easily.
>>>
>>
>>Again, show an example.
>
>
> Okay. I fixed a bug about three or four months ago in which someone
> called Thread.sleep using an instance reference, and expected it to put
> a different thread to sleep. See? The instance method syntax caused
> confusion, by implying that the method "sleep" acted on a specific other
> instance, when it really doesn't.

This is a good example to prove my point. Here you have a
static method, Thread.sleep, that operates on a specific
thread instance (the current thread). There is nothing
wrong with that since it's fully documented to work that
way. However, the coder you mentioned fell under the spell
of your recommended coding convention, didn't bother to read
the documentation, and assumed calling
someOtherThreadInstance.sleep would work. The coding
convention led to sloppy thinking and a bug, which, as you
put it, could be dangerous.

You didn't say how you coded your fix, but if you just used
a call like Thread.sleep, then you weren't following your
recommended coding convention either. To do so, you would
have to code something like
Thread thisThread = Thread.currentThread();
thisThread.sleep(...);

But most wouldn't bother with that, they would just
call Thread.sleep(...);

>>Let's not confuse things by extending the argument to "any
>>arbitrary change". No-one said that.
>
> Right. I'm *trying* to prompt you to tell me why you think that
> instance and static methods ought to be interchangable... but you're not
> taking the hint. So why is it?
>
I just don't believe I should have to understand how a class
and its instances are implemented and what their inheritance
hierarchy is in order to follow this coding convention. I
don't know how fully you intend to go with it, but if
there's some class inheritance hierarchy like A.B.C.D
and I have an instance of D called d, and I want to invoke
some static method that happens to be defined up in B, are
you suggesting I code B.methodB(), and then for some method
in A, A.methodA(), and for C, C.methodC()? So I should
encode the class hierarchy in all my calls to static methods
(after I first research it all to see what's static and what
isn't) ?? I can tell you right now I ain't doin' that. And
if you say, no, I can just use D.methodB(), then I say
that's no better than d.methodB().

Another reason I might not follow the guideline is when the
class name happens to be 38 characters long, one of which I
saw yesterday. If I happened to need to invoke one of its
static methods more than once in my code and I didn't have
an instance handy, I would probably make an instance of that
for the sole purpose of shortening the name down, and I
would call all its static methods thru that instance.

You say that's twisted, but I say it makes the code more
readable.

Rick

Relevant Pages

  • [OT] bugs in c
    ... I agree that that is a bug if you define it in that way. ... The fact that you can call static methods via instance ... references is clearly brain-dead language design. ... the method is static (and thus skips over polymorphism entirely) or ...
    (comp.lang.c)
  • is bug 34739 really closed?
    ... used when calling static methods"; however this is not a call to a ... Should the bug be reopen? ... public function __call ... class test2 extends test ...
    (php.general)
  • Re: is bug 34739 really closed?
    ... used when calling static methods"; however this is not a call to a ... Should the bug be reopen? ... class test2 extends test ... If you're calling it with:: you're calling it statically. ...
    (php.general)