10 Reasons We Need Java 3.0
Subject:   Interface naming collisions
Date:   2002-08-06 09:30:26
From:   nielsen
Here's something else that needs to be fixed. It requires a major redesign:

I have two interfaces and both have a method with the same name, let's say 'close'. If I want to implement them in the same class but have different things happen for either close method, I can't.

Basic design flaw.

Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • Interface naming collisions
    2002-08-27 17:44:14  piobair [View]

    I'd say its more a design flaw in your model, then Java. If close() has two meanings you probably ought to be more explicit about what/how your closing.
  • Interface naming collisions
    2002-08-06 10:40:32  wmshub [View]

    But there's already a solution! Just use an inner class instead. I almost never implement interfaces in my "main" classes, so instead of:

    public class Foo
    implements Bar, Baz {

    public void close() { /* Is this Bar.close or Baz.close? Oh no! */

    you can write:

    public class Foo {
    public final Bar bar = new Bar() {
    public void close() {

    public final Baz baz = new Baz() {
    public void close() {

    private void barClose() { ... }
    private void bazClose() { ... }

    Problem solved! Now just use when you need the Bar interface and foo.baz when you need the Baz interface.

    My only complaint is that it's a very verbose mneumonic. I'd prefer "thin" classes, like:
    public thin Bar bar = Bar() { close=barClose };
    to say "Bar is an inner bar object, but its close is equal to the bazClose in the outer object". Much easier to read.
  • Interface naming collisions
    2002-08-06 09:38:49  rpkrajewski [View]

    Amen !

    In Common Lisp, object functions are just functions and are thus subject to namespace/package partitioning. In Java, by contrast, member selection and the namespace syntax both use ".", which would make any new syntax for letting members belong to packages a bit ugly or different.