interface.methodname style declarations

T

Timo Nentwig

Hi!

I like short method names that describe just their purpose in their scope.
So, I prefer moved() to mouseMoved() since I know that it all about mouse
movements.

class Blah implement MouseListener
{
public void moved(int x, int y)
{
}
}

But I ran into problems with such general and simple method names when I
implement an interface with such method names and my class already declares
a method with such a name as well.

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
// and does have nothing to do with
// mouse moves at all
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void moved(int x, int y)
{
]
}

So, what I'm going to do is to use an MouseAdapter and an inner class. But I
would like to propose the following:

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void MouseListener.moved(int x, int y)
{
]
}


What do you think?
 
D

Dale King

Timo Nentwig said:
Hi!

I like short method names that describe just their purpose in their scope.
So, I prefer moved() to mouseMoved() since I know that it all about mouse
movements.

class Blah implement MouseListener
{
public void moved(int x, int y)
{
}
}

But I ran into problems with such general and simple method names when I
implement an interface with such method names and my class already declares
a method with such a name as well.

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
// and does have nothing to do with
// mouse moves at all
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void moved(int x, int y)
{
]
}

So, what I'm going to do is to use an MouseAdapter and an inner class. But I
would like to propose the following:

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void MouseListener.moved(int x, int y)
{
]
}


What do you think?

I think you should learn to name your methods better so that the name is
clear and unambiguous without having to know the context.

I disagee with your statement that you do know that it is all about a mouse.
That may be clear when looking only at the interface. But in a class
implementing that interface it is just one of maybe 50 methods. I wouldn't
want to see a moved method among all these other methods and wonder, "what
moved?". A worse case would be a method named pressed in a listener for
mouse events and the same in a listener for key events.

And your suggestion will never work in Java.
 
A

ak

you can write your own MouseAdapter:

class ShortMouseAdapter implements MouseListener {
public void mousePressed(MouseEvent e) {
pressed(e);
}

public void pressed(MouseEvent e) {
//do something
}
}

but this is ugli.


Dale King said:
Timo Nentwig said:
Hi!

I like short method names that describe just their purpose in their scope.
So, I prefer moved() to mouseMoved() since I know that it all about mouse
movements.

class Blah implement MouseListener
{
public void moved(int x, int y)
{
}
}

But I ran into problems with such general and simple method names when I
implement an interface with such method names and my class already declares
a method with such a name as well.

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
// and does have nothing to do with
// mouse moves at all
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void moved(int x, int y)
{
]
}

So, what I'm going to do is to use an MouseAdapter and an inner class.
But
I
would like to propose the following:

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void MouseListener.moved(int x, int y)
{
]
}


What do you think?

I think you should learn to name your methods better so that the name is
clear and unambiguous without having to know the context.

I disagee with your statement that you do know that it is all about a mouse.
That may be clear when looking only at the interface. But in a class
implementing that interface it is just one of maybe 50 methods. I wouldn't
want to see a moved method among all these other methods and wonder, "what
moved?". A worse case would be a method named pressed in a listener for
mouse events and the same in a listener for key events.

And your suggestion will never work in Java.
 
T

Timo Nentwig

Dale said:
class implementing that interface it is just one of maybe 50 methods. I
wouldn't want to see a moved method among all these other methods and
wonder, "what moved?". A worse case would be a method named pressed in a
listener for mouse events and the same in a listener for key events.

Did you read my posting at all?

That's why

public void MouseListener.moved(int x, int y)
{
}

and you still can use an adapter.
 
C

Chris Uppal

Timo said:
Dale said:
Did you read my posting at all?

It may be that he didn't catch that you were proposing a modification to the
Java language definition, rather than suggesting a programming technique.
That's why

public void MouseListener.moved(int x, int y)
{
}

and you still can use an adapter.

But nevertheless Dale was right; that cannot work in Java (or Java+) because
there is no way of translating it into something that the JVM will understand.

(Well, *I* can't think of a translation, anyway)

-- chris
 
J

John C. Bollinger

Timo said:
Hi!

I like short method names that describe just their purpose in their scope.
So, I prefer moved() to mouseMoved() since I know that it all about mouse
movements.

class Blah implement MouseListener
{
public void moved(int x, int y)
{
}
}

But I ran into problems with such general and simple method names when I
implement an interface with such method names and my class already declares
a method with such a name as well.

I have to second Dale's point that it is precisely for this reason that
it makes sense to name interface methods in specific and unambiguous ways.

[...]
So, what I'm going to do is to use an MouseAdapter and an inner class.

That is certainly feasible, and it makes sense if you want to clean up
your class' public interface or restrict access to the mouse callbacks.
It is not necessary, however, since MouseAdapter / MouseListener
provide nice, descriptive names that are rarely ambiguous.
But I
would like to propose the following:

class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void MouseListener.moved(int x, int y)
{
]
}


What do you think?

I think the existing method names achieve the same end in a simpler way.
I think I see a way to support it on the current JVM (it would
involve the compiler creating a synthetic inner class), but what
contorted gymnastics! Yuck.


John Bollinger
(e-mail address removed)
 
D

Dale King

Timo Nentwig said:
Did you read my posting at all?

Yes. Most of my comments were not about the requested change, but about the
motivation behind your requested change. My point was that the idea of
shortening the name down to where it only has meaning if you know the
context is a bad practice. Even ignoring name collisions you have a bad
situation. Despite your claim otherwise you don't know the method is
referring to at the point of implementing it. Sure, it makes sense when
looking only at the interface defintion, but in a class that implements
interface it is only a method among many. There is nothing that associates
the moved method with the fact that it is movement of the mouse. The only
connection is to see that it implements the interface.

So, sure they could do a major tear-up to the language and the JVM spec to
support your bad programming practice. But I think you should eliminate the
poor programming practice instead of asking them to go to great lengths to
allow you to make up for the bad idea.
That's why

public void MouseListener.moved(int x, int y)
{
}

and you still can use an adapter.

But once again, there is no way to make that work in Java. It would be a
major change to the JVM to be able to support that. And in case you didn't
know it there has not been an incompatible change in the format of class
files yet. You can still run 1.4 generated classes on an original 1.0.2
vintage JVM, even using fancy features like inner classes that were not
introduced until 1.1.
 
D

Dale King

Chris Uppal said:
Timo said:
Dale said:
Did you read my posting at all?

It may be that he didn't catch that you were proposing a modification to the
Java language definition, rather than suggesting a programming technique.

No, I caught it. I was arguing that the motivation for the change was based
on a desire to use a bad programming practice. The language should not be
changed to make this practice easier. Instead he should be using clear,
unambiguous names that do not depend on context.

You can still run into name collisions, but they are rare. His practice
makes them pretty much a certainty.
But nevertheless Dale was right; that cannot work in Java (or Java+) because
there is no way of translating it into something that the JVM will understand.

(Well, *I* can't think of a translation, anyway)

It could probably be done somehow, but I can't think of any way that would
be supported by any current JVM.
 
T

Timo Nentwig

Dale said:
files yet. You can still run 1.4 generated classes on an original 1.0.2
vintage JVM, even using fancy features like inner classes that were not

No, you can't. You cannot even run 1.4 (v48) generated classes on a 1.3 JVM.

I got a "bug report" just two days somebody complaining that an
java.lang.UnsupportedClassVersionError is thrown.
 
T

Timo Nentwig

Timo said:
class Blah extends Mover implement MouseListener
{
// extends Mover or simple part of Blah
public void moved(int x, int y)
{
}

// interface method of MouseListener
public void MouseListener.moved(int x, int y)
{
]
}

And, removing "implement MouseListener" could make the compiler tell you to
remove MouseListener.moved() as well in case you forgot. This happened
quite a few times to me (when not using Adapters).
 
D

Dale King

Timo Nentwig said:
No, you can't. You cannot even run 1.4 (v48) generated classes on a 1.3 JVM.

I got a "bug report" just two days somebody complaining that an
java.lang.UnsupportedClassVersionError is thrown.

Yes, you can. Beginning with 1.4, it just isn't the default behavior for the
compiler any more. See the -target option for the compiler. If you set that
to -target 1.1 you should have no problem. For JDK1.4.x, the default value
is now -target 1.2. If you are having problems running on a 1.3 VM then it
sounds like you are using -target 1.4.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top