interface.methodname style declarations

Discussion in 'Java' started by Timo Nentwig, Nov 6, 2003.

  1. Timo Nentwig

    Timo Nentwig Guest

    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?
     
    Timo Nentwig, Nov 6, 2003
    #1
    1. Advertising

  2. Timo Nentwig

    Dale King Guest

    "Timo Nentwig" <> wrote in message
    news:boecbv$1dsglh$-berlin.de...
    > 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.

    --
    Dale King
     
    Dale King, Nov 6, 2003
    #2
    1. Advertising

  3. Timo Nentwig

    ak Guest

    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" <> schrieb im Newsbeitrag
    news:...
    > "Timo Nentwig" <> wrote in message
    > news:boecbv$1dsglh$-berlin.de...
    > > 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.
    >
    > --
    > Dale King
    >
    >
     
    ak, Nov 7, 2003
    #3
  4. Timo Nentwig

    Timo Nentwig Guest

    ak wrote:

    > you can write your own MouseAdapter:


    >> > So, what I'm going to do is to use an MouseAdapter and an inner class.
     
    Timo Nentwig, Nov 7, 2003
    #4
  5. Timo Nentwig

    Timo Nentwig Guest

    Dale King wrote:
    > 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.
     
    Timo Nentwig, Nov 7, 2003
    #5
  6. Timo Nentwig

    Chris Uppal Guest

    Timo Nentwig wrote:

    > Dale King wrote:
    > > [snip]

    > 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
     
    Chris Uppal, Nov 7, 2003
    #6
  7. Timo Nentwig wrote:

    > 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
     
    John C. Bollinger, Nov 7, 2003
    #7
  8. Timo Nentwig

    Dale King Guest

    "Timo Nentwig" <> wrote in message
    news:bofiks$1dab78$-berlin.de...
    > Dale King wrote:
    > > 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?


    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.

    --
    Dale King
     
    Dale King, Nov 7, 2003
    #8
  9. Timo Nentwig

    Dale King Guest

    "Chris Uppal" <-THIS.org> wrote in message
    news:3fab7345$0$111$...
    > Timo Nentwig wrote:
    >
    > > Dale King wrote:
    > > > [snip]

    > > 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.
    --
    Dale King
     
    Dale King, Nov 7, 2003
    #9
  10. Timo Nentwig

    Timo Nentwig Guest

    Dale King wrote:
    > 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.
     
    Timo Nentwig, Nov 8, 2003
    #10
  11. Timo Nentwig

    Timo Nentwig Guest

    Timo Nentwig wrote:
    > 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).
     
    Timo Nentwig, Nov 8, 2003
    #11
  12. Timo Nentwig

    Dale King Guest

    "Timo Nentwig" <> wrote in message
    news:boi816$2v7ki$-berlin.de...
    > Dale King wrote:
    > > 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.


    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.

    --
    Dale King
     
    Dale King, Nov 10, 2003
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jan V
    Replies:
    15
    Views:
    658
    Dale King
    Sep 12, 2005
  2. Michael B.

    K&R-Style Function Declarations: Good or Bad?

    Michael B., Dec 8, 2003, in forum: C Programming
    Replies:
    28
    Views:
    1,923
    Dan Pop
    Dec 10, 2003
  3. john
    Replies:
    8
    Views:
    372
    Nick Keighley
    Jun 22, 2010
  4. Ken Varn
    Replies:
    0
    Views:
    473
    Ken Varn
    Apr 26, 2004
  5. droesler
    Replies:
    2
    Views:
    513
    droesler
    Aug 31, 2010
Loading...

Share This Page