🚀 go-pugleaf

What specific Interface.method() names are you experiencing clashes
with? -Ralph

Nothing in particular, it's a general observation related to custom
interfaces:

interface Intf1{
    public void X();
}

interface Intf2{
    public void X();
}

class MyClass implements Intf1, Intf2{
    ????
}

"Ralph Vince" <rvince99@earthlink.net> wrote in message
news:JScP8.111$Fv1.17660@newsread2.prod.itd.earthlink.net...
> What specific Interface.method() names are you experiencing clashes
> with? -Ralph
>
>

> Nothing in particular, it's a general observation related to custom
> interfaces:
>
> interface Intf1{
>     public void X();
> }
>
> interface Intf2{
>     public void X();
> }
>
> class MyClass implements Intf1, Intf2{
>     ????
> }

By observation, it seems silly to implement two or more interfaces with the
same abstract methods. First because its extraneous, and second because of
the name clashes. How is Java suppose to know which abstract methods
requries implementation? How do other programming languages resolve this
problem?

"Sted Alana" <Sted_Alana@hotmail.com> wrote in message
news:3d0d7f8d_1@news.iprimus.com.au...
>
> > Nothing in particular, it's a general observation related to custom
> > interfaces:
> >
> > interface Intf1{
> >     public void X();
> > }
> >
> > interface Intf2{
> >     public void X();
> > }
> >
> > class MyClass implements Intf1, Intf2{
> >     ????
> > }
>
> By observation, it seems silly to implement two or more interfaces with
the
> same abstract methods. First because its extraneous, and second because of
> the name clashes. How is Java suppose to know which abstract methods
> requries implementation? How do other programming languages resolve this
> problem?
>

Hi Sted,

Well, you might get two such interfaces from two independant libraries. They
could *easily* have a name clash. An example I like (I can't give credit
because of my poor memory, but it was someone on one of the java newsgroups
who gave it, I think) is the example of Draw() being used in the context of
a lottery library and also in the context of a graphics library. If you use
both of these libraries in an App that graphically displays lottery draws,
you might get a name clash in a class that "draws a draw" (if you see what I
mean).

The best way for dealing with this that I have seen is in Delphi (object
pascal), in which you can have "name-resolution" statements in your class
declaration. So you can say Intf1.X()=MyClass.Interface1X(), and then calls
to that interface method [X()]will get mapped to the specified method
[Interface1X()].

Regards,
Tristan

Sted Alana <Sted_Alana@hotmail.com> wrote:

: By observation, it seems silly to implement two or more interfaces with the
: same abstract methods. First because its extraneous, and second because of
: the name clashes. How is Java suppose to know which abstract methods
: requries implementation?

: How do other programming languages resolve this problem?

See "What about name clashes" on:

http://www.eiffel.com/doc/manuals/technology/bmarticles/joop/multiple.html
-- 
__________
 |im |yler  http://timtyler.org/  tim@tt1.org

Tristan Reeves <moonshine@apex.net.au> wrote:

: I was saddened to find out that Java fails miserably in implemeting multiple
: interfaces which share a method signature.

They got rid of most of multiple inheritance - but managed to keep the
worst bit :-|
-- 
__________
 |im |yler  http://timtyler.org/  tim@tt1.org

Tristan Reeves <moonshine@apex.net.au> wrote:

: The best way for dealing with this that I have seen is in Delphi (object
: pascal), in which you can have "name-resolution" statements in your class
: declaration. So you can say Intf1.X()=MyClass.Interface1X(), and then calls
: to that interface method [X()]will get mapped to the specified method
: [Interface1X()].

That is also - more or less - what Eiffel does.

http://www.elj.com/eiffel/ij/inheritance/mi/ describes the problem
with C++:

''In C++, you must use the scope resolution operator in the code, every
  time you run into an ambiguity problem between two or more members. This
  clutters the code, and makes it less malleable, as if anything changes
  that affects the ambiguity, you potentially have to change the code
  everywhere, where the ambiguity occurs.''

 - http://www.elj.com/eiffel/ij/inheritance/mi/

Eiffel advocates renaming - through inheritance.  That way - if you get a
name clash - you don't have to go through all the existing code renaming
all the calls to the newly-ambiguous method - and you can still find the
names of the methods you are interested in the class where they are called.

Could Java be changed to do things that way?  I don't see why not.
-- 
__________
 |im |yler  http://timtyler.org/  tim@tt1.org

>Nothing in particular, it's a general observation related to custom
>interfaces:
>
>interface Intf1{
>    public void X();
>}
>
>interface Intf2{
>    public void X();
>}
>
>class MyClass implements Intf1, Intf2{
>    ????
>}

It just highlights the importance of choosing method names very
carefully, especially so in interfaces.

It does not highlight a major problem in the language, as you seem to
suggest. In 6 years of Java programming I don't recall ever being
faced with method name collisions due to implementing several
interfaces.

  L.

==
Check out JINX - The Java Information Exchange, http://jinx.swiki.net

"Laurence V" <o@o> wrote in message news:3d0d962f.216399@news.clara.net...
> >Nothing in particular, it's a general observation related to custom
> >interfaces:
> >
> >interface Intf1{
> >    public void X();
> >}
> >
> >interface Intf2{
> >    public void X();
> >}
> >
> >class MyClass implements Intf1, Intf2{
> >    ????
> >}
>
> It just highlights the importance of choosing method names very
> carefully, especially so in interfaces.
>
> It does not highlight a major problem in the language, as you seem to
> suggest. In 6 years of Java programming I don't recall ever being
> faced with method name collisions due to implementing several
> interfaces.
>
>   L.
>
> ==
> Check out JINX - The Java Information Exchange, http://jinx.swiki.net

Of course it is an ugly problem in the language, even if not a show-stopper.

Just because you haven't encountered one doesn't mean there will never be a
name clash. It doesn't matter how carefully you choose your method names;
different domains use the same word for different concepts, besides which it
is ridiculous to have to tweak method names like "Open" or "Draw" - which
are perfectly fine - just because someone else *might* be using them. Trying
to puzzle out whether or not a given word is in use in some unknown
interface somewhere else on this planet is fruitless. At best you can hope.

Even if name-clashes are rare, it seems to me that there is just no good
reason why a name resolution technique could not have been implemented in
the language.

Regards,
Tristan.

"Tristan Reeves" <moonshine@apex.net.au> wrote in message
news:1024306483.86878@web.apex.net.au...
>
>
> Of course it is an ugly problem in the language, even if not a
show-stopper.
>
> Just because you haven't encountered one doesn't mean there will never be
a
> name clash. It doesn't matter how carefully you choose your method names;
> different domains use the same word for different concepts, besides which
it
> is ridiculous to have to tweak method names like "Open" or "Draw" - which
> are perfectly fine - just because someone else *might* be using them.
Trying
> to puzzle out whether or not a given word is in use in some unknown
> interface somewhere else on this planet is fruitless. At best you can
hope.
>
> Even if name-clashes are rare, it seems to me that there is just no good
> reason why a name resolution technique could not have been implemented in
> the language.
>
>

I agree with Laurence that this is only a minor problem (and in practice a
very rare one at that). This is partly because a clash only occurs if the
method name AND signature match. So in the rare cases that a clash does
occur we have to use delegation. I think this is quite a small price to pay
for avoiding the extra complication of name resolution. With a reasonable
JIT the run time cost of delegation is negligible.

Mark Thornton

On Mon, 17 Jun 2002 00:56:34 -0400, Tristan Reeves wrote:

> Nothing in particular, it's a general observation related to custom
> interfaces:
> 
> interface Intf1{
>     public void X();
> }
> 
> interface Intf2{
>     public void X();
> }
> 
> class MyClass implements Intf1, Intf2{
>     ????
> }

What's the problem with the above? In true multiple inheritance, where
you're inheriting multiple _implementations_, the diamond-of-death occurs
where you're not sure which _inherited_ implementation to invoke first,
or whether it's desirable to invoke one first. With Java, you have
multiple inheritance on at the _interface_ level, which alleviates the
diamond-of-death problem: you only have one inherited implementation on
_any_ method, and that solves the problem of "which inherited
implementation to invoke first".

HTH.

-- 
/**
 * @author Darryl L. Pierce <mcpierce@databasix.com>
 * @see    The Infobahn Offram <http://welcome.to/mcpierce>
 * @quote  "What do you care what other people think, Mr. Feynman?"
 */

I'd be interested to hear what alternatives there are. Throwing a
compile error would be yet a worse solution. The only true problem it
causes is when there are different implementations necessary for each
of the operations. And while this could be a problem, it's never
surfaced on any of the teams I've worked with.

Kirk Knoernschild
Senior Consultant/Instructor
TeamSoft, Inc.
Mentoring, Training, Consulting
www.teamsoftinc.com
www.kirkk.com

"Tristan Reeves" <moonshine@apex.net.au> wrote in message news:<1024283082.192985@web.apex.net.au>...
> Hi,
> 
> I am fairly new to Java, and I am sure this question has been raised on
> numerous occasions. Nevertheless...
> 
> I was saddened to find out that Java fails miserably in implemeting multiple
> interfaces which share a method signature. I know the standard contorsion of
> using inner classes, one for each interface, have the inner classes delegate
> to a method on the outer class, and then allowing access to instances of
> these inner classes via an accessor method on the outer class.
> 
> Does anyone know if there are any plans to fix this ridiculous state of
> affairs? Or, is there any other way to resolve name-clashes?
> 
> Regards,
> Tristan.

I think I would agree with that.

Tristan.

"Mark Thornton" <mthornton@optrak.co.uk> wrote in message
news:3d0db19e$0$7200$afc38c87@news.easynet.co.uk...
>
> "Tristan Reeves" <moonshine@apex.net.au> wrote in message
> news:1024306483.86878@web.apex.net.au...
> >
> >
> > Of course it is an ugly problem in the language, even if not a
> show-stopper.
> >
> > Just because you haven't encountered one doesn't mean there will never
be
> a
> > name clash. It doesn't matter how carefully you choose your method
names;
> > different domains use the same word for different concepts, besides
which
> it
> > is ridiculous to have to tweak method names like "Open" or "Draw" -
which
> > are perfectly fine - just because someone else *might* be using them.
> Trying
> > to puzzle out whether or not a given word is in use in some unknown
> > interface somewhere else on this planet is fruitless. At best you can
> hope.
> >
> > Even if name-clashes are rare, it seems to me that there is just no good
> > reason why a name resolution technique could not have been implemented
in
> > the language.
> >
> >
>
> I agree with Laurence that this is only a minor problem (and in practice a
> very rare one at that). This is partly because a clash only occurs if the
> method name AND signature match. So in the rare cases that a clash does
> occur we have to use delegation. I think this is quite a small price to
pay
> for avoiding the extra complication of name resolution. With a reasonable
> JIT the run time cost of delegation is negligible.
>
> Mark Thornton
>
>
>

1) If you are implementing more than a few interfaces in one class you are
probably doing too much in one class and probably have poor design.

2) If you have this problem you also have a poor naming convention.

Jeff Dillon


"Tristan Reeves" <moonshine@apex.net.au> wrote in message
news:1024283082.192985@web.apex.net.au...
> Hi,
>
> I am fairly new to Java, and I am sure this question has been raised on
> numerous occasions. Nevertheless...
>
> I was saddened to find out that Java fails miserably in implemeting
multiple
> interfaces which share a method signature. I know the standard contorsion
of
> using inner classes, one for each interface, have the inner classes
delegate
> to a method on the outer class, and then allowing access to instances of
> these inner classes via an accessor method on the outer class.
>
> Does anyone know if there are any plans to fix this ridiculous state of
> affairs? Or, is there any other way to resolve name-clashes?
>
> Regards,
> Tristan.
>
>

"Jeff Dillon" <jeff@jeffdillon.com> wrote in message
news:EzxP8.238919$cQ3.10063@sccrnsc01...
> 1) If you are implementing more than a few interfaces in one class you are
> probably doing too much in one class and probably have poor design.

What about TWO interfaces?

> 2) If you have this problem you also have a poor naming convention.
>
> Jeff Dillon

Crap.
As I have said repeatedly, they may not be *your* interfaces.

>
> "Tristan Reeves" <moonshine@apex.net.au> wrote in message
> news:1024283082.192985@web.apex.net.au...
> > Hi,
> >
> > I am fairly new to Java, and I am sure this question has been raised on
> > numerous occasions. Nevertheless...
> >
> > I was saddened to find out that Java fails miserably in implemeting
> multiple
> > interfaces which share a method signature. I know the standard
contorsion
> of
> > using inner classes, one for each interface, have the inner classes
> delegate
> > to a method on the outer class, and then allowing access to instances of
> > these inner classes via an accessor method on the outer class.
> >
> > Does anyone know if there are any plans to fix this ridiculous state of
> > affairs? Or, is there any other way to resolve name-clashes?
> >
> > Regards,
> > Tristan.
> >
> >
>
>

"Tristan Reeves" <moonshine@apex.net.au> wrote in message
news:1024391253.156369@web.apex.net.au...
>
> "Jeff Dillon" <jeff@jeffdillon.com> wrote in message
> news:EzxP8.238919$cQ3.10063@sccrnsc01...
> > 1) If you are implementing more than a few interfaces in one class you
are
> > probably doing too much in one class and probably have poor design.
>
> What about TWO interfaces?

I find in very rare to have to implement even two interfaces within the same
class. As Jeff said - it's very possible you are trying to do too much in
one class. Good OO design usually implies high cohesion.

>
> > 2) If you have this problem you also have a poor naming convention.
> >
> > Jeff Dillon
>
> Crap.
> As I have said repeatedly, they may not be *your* interfaces.
>


Can you give us actual examples of the problems you are having, rather than
just generalising ? (Seriously - I am interested in seeing these name
clashes and thinking about possible solutions).

Rus.

Use Facets.

interface Intf1{
     public void X();
}

interface Intf2{
     public void X();
}

class MyClass
{
      private void intf2X()
      {
         // do interface 2 X() implementation
      }

      private void intf1X()
      {
         // do interface 1 X() impementation
      }

     Intf1  getIntf1()
     {
        return new Intf1()
        {
           public void X()
           {
              intf1X();
           }
        };
     }

     Intf2  getIntf2()
     {
        return new Intf2()
        {
           public void X()
           {
              intf2X();
           }
        };
     }
}

Then you can use   myclassinstance.getIntf2().X() or 
myclassinstance.getIntf2().X() depending which you want to use/call.


Rich.

Darryl L. Pierce wrote:
> On Mon, 17 Jun 2002 00:56:34 -0400, Tristan Reeves wrote:
> 
> 
>>Nothing in particular, it's a general observation related to custom
>>interfaces:
>>
>>interface Intf1{
>>    public void X();
>>}
>>
>>interface Intf2{
>>    public void X();
>>}
>>
>>class MyClass implements Intf1, Intf2{
>>    ????
>>}
> 
> 
> What's the problem with the above? In true multiple inheritance, where
> you're inheriting multiple _implementations_, the diamond-of-death occurs
> where you're not sure which _inherited_ implementation to invoke first,
> or whether it's desirable to invoke one first. With Java, you have
> multiple inheritance on at the _interface_ level, which alleviates the
> diamond-of-death problem: you only have one inherited implementation on
> _any_ method, and that solves the problem of "which inherited
> implementation to invoke first".
> 
> HTH.
> 



-- 
http://www.krang.f9.co.uk

Russell Dodd <rdodd@alterian.com> wrote:

:> > 1) If you are implementing more than a few interfaces in one class you
:> > are probably doing too much in one class and probably have poor design.
:>
:> What about TWO interfaces?

: I find in very rare to have to implement even two interfaces within the same
: class.

Common stuff for others, though:

public final class String implements Comparable, Serialisable {
public class Date implements Clonable, Comparable, Serialisable {
public final class Character implements Clonable, Serialisable {
public class BitSet implements Clonable, Serialisable {
public class RandomAccessFile implements DataInput, DataOutput {
-- 
__________
 |im |yler  http://timtyler.org/  tim@tt1.org

Are you aware that both Cloneable and Serializable are interfaces that do
not have any methods? They are therefore exceptions. They are placeholders
of sorts to merely indicate semantics.

Jeff Dillon

"Tim Tyler" <tim@tt1.org> wrote in message news:Gxx609.3u6@bath.ac.uk...
> Russell Dodd <rdodd@alterian.com> wrote:
>
> :> > 1) If you are implementing more than a few interfaces in one class
you
> :> > are probably doing too much in one class and probably have poor
design.
> :>
> :> What about TWO interfaces?
>
> : I find in very rare to have to implement even two interfaces within the
same
> : class.
>
> Common stuff for others, though:
>
> public final class String implements Comparable, Serialisable {
> public class Date implements Clonable, Comparable, Serialisable {
> public final class Character implements Clonable, Serialisable {
> public class BitSet implements Clonable, Serialisable {
> public class RandomAccessFile implements DataInput, DataOutput {
> --
> __________
>  |im |yler  http://timtyler.org/  tim@tt1.org

On Tue, 18 Jun 2002 19:40:17 +0100, "Coho (Richard Swain)"
<vibron@krang.f9.co.uk> wrote:

>Use Facets.
>
>interface Intf1{
>     public void X();
>}
>
>interface Intf2{
>     public void X();
>}
>
>class MyClass
>{
>      private void intf2X()
>      {
>         // do interface 2 X() implementation
>      }
>
>      private void intf1X()
>      {
>         // do interface 1 X() impementation
>      }
>
>     Intf1  getIntf1()
>     {
>        return new Intf1()
>        {
>           public void X()
>           {
>              intf1X();
>           }
>        };
>     }
>
>     Intf2  getIntf2()
>     {
>        return new Intf2()
>        {
>           public void X()
>           {
>              intf2X();
>           }
>        };
>     }
>}
>
>Then you can use   myclassinstance.getIntf2().X() or 
>myclassinstance.getIntf2().X() depending which you want to use/call.
>


Hmm. I see the idea, but it's not exactly polymorphic, is it. You
almost need to create a new interface:

interface ThingThatDoesIntf1AndIntf2 {
    Intf1 getIntf1();
    intf2 getIntf2();
}

Except that you can't even pass this object round to a method that
expects to be given an Intf1 or an Intf2.

Steve

Steve Horsley wrote:
> On Tue, 18 Jun 2002 19:40:17 +0100, "Coho (Richard Swain)"
> <vibron@krang.f9.co.uk> wrote:
> 
> 
>>Use Facets.
>>
>>interface Intf1{
>>    public void X();
>>}
>>
>>interface Intf2{
>>    public void X();
>>}
>>
>>class MyClass
>>{
>>     private void intf2X()
>>     {
>>        // do interface 2 X() implementation
>>     }
>>
>>     private void intf1X()
>>     {
>>        // do interface 1 X() impementation
>>     }
>>
>>    Intf1  getIntf1()
>>    {
>>       return new Intf1()
>>       {
>>          public void X()
>>          {
>>             intf1X();
>>          }
>>       };
>>    }
>>
>>    Intf2  getIntf2()
>>    {
>>       return new Intf2()
>>       {
>>          public void X()
>>          {
>>             intf2X();
>>          }
>>       };
>>    }
>>}
>>
>>Then you can use   myclassinstance.getIntf2().X() or 
>>myclassinstance.getIntf2().X() depending which you want to use/call.
>>> 
> 
> Hmm. I see the idea, but it's not exactly polymorphic, is it. You
> almost need to create a new interface:
> 
> interface ThingThatDoesIntf1AndIntf2 {
>     Intf1 getIntf1();
>     intf2 getIntf2();
> }
> 
> Except that you can't even pass this object round to a method that
> expects to be given an Intf1 or an Intf2.

But I don't see how using somekind of namespace resolution is 
polymorphic either. i.e to specify which method to call you *have*
to specify the interface the method is on. IMHO getIntfN() does that 
just as well as some kind of language trick.

You are right about specifying a new interface, but I would hope that 
practically all concrete classes are expressions of interfaces - to 
which those two methods can be added.

If a method takes a particular interface intf1 say you can always do

theMethod( myclass.getIntf1() );

and within that if you need to get hold of the other interface just do

    Intf2 f2 = ((ThingThatDoesIntf1AndIntf2)fi).getIntf2();

For your last point. If a method takes an object of type intf1 *or* 
intf2 I'm not quite sure how it suppose to know which X() is the one to 
be called internally unless they they are functionally equivalent and 
hence the same method, or unless the object being passed in is only an 
implementation of one of the interfaces, in which case no specific 
resolution is required.

Anyway, just to get it past the compiler you could change 
ThingThatDoesIntf1AndIntf2 to

interface ThingThatDoesIntf1AndIntf2 implements intf1 and intf2
{...

If you still have doubts (maybe I am missing something) a concrete 
example would be appreciated.

Rich.


> Steve



-- 
http://www.krang.f9.co.uk

"Darryl L. Pierce" <mcpierce@databasix.com> wrote in
news:pan.2002.06.17.07.46.24.235390.777@databasix.com: 

> On Mon, 17 Jun 2002 00:56:34 -0400, Tristan Reeves wrote:
> 
>> Nothing in particular, it's a general observation related to custom
>> interfaces:
>> 
>> interface Intf1{
>>     public void X();
>> }
>> 
>> interface Intf2{
>>     public void X();
>> }
>> 
>> class MyClass implements Intf1, Intf2{
>>     ????
>> }
> 
> What's the problem with the above? In true multiple inheritance, where
> you're inheriting multiple _implementations_, the diamond-of-death
> occurs where you're not sure which _inherited_ implementation to
> invoke first, or whether it's desirable to invoke one first. With
> Java, you have multiple inheritance on at the _interface_ level, which
> alleviates the diamond-of-death problem: you only have one inherited
> implementation on 

I'm sorry.  What exactly is the "the diamond-of-death?"


-- 
----- BEGIN GEEK CODE BLOCK -----
Version: 3.12
GCS d++ s a C+ UC++++ P+ L E- W+ N++ o- K++ w+ O+ M !V PS+ PE Y+ PGP t+
!5 X- R- tv--- b++ DI++ D+ G+ e+ h---- r+++ y+ ------ END GEEK CODE
BLOCK ------ 

On Wed, 19 Jun 2002 23:12:14 +0100, "Coho (Richard Swain)"
<vibron@krang.f9.co.uk> wrote:

>> almost need to create a new interface:
>> 
>> interface ThingThatDoesIntf1AndIntf2 {
>>     Intf1 getIntf1();
>>     intf2 getIntf2();
>> }
>> 
>> Except that you can't even pass this object round to a method that
>> expects to be given an Intf1 or an Intf2.
>
>But I don't see how using somekind of namespace resolution is 
>polymorphic either. i.e to specify which method to call you *have*
>to specify the interface the method is on. IMHO getIntfN() does that 
>just as well as some kind of language trick.
>
Me neither. Perhaps the best approach is to use a convention like:
    public void intf1_draw()...
    public void intf2_draw()...
but I don't think people are likely to adopt it.

>You are right about specifying a new interface, but I would hope that 
>practically all concrete classes are expressions of interfaces - to 
>which those two methods can be added.
>
>If a method takes a particular interface intf1 say you can always do
>
>theMethod( myclass.getIntf1() );
>
That's not too bad. Except that there's no way to get back from the
Intf1 to the original myClass object. I'm not sure you should ever
want to, but I still feel alienated by this somehow.

>and within that if you need to get hold of the other interface just do
>
>    Intf2 f2 = ((ThingThatDoesIntf1AndIntf2)fi).getIntf2();
>
>For your last point. If a method takes an object of type intf1 *or* 
>intf2 I'm not quite sure how it suppose to know which X() is the one to 
>be called internally unless they they are functionally equivalent and 
>hence the same method, or unless the object being passed in is only an 
>implementation of one of the interfaces, in which case no specific 
>resolution is required.

Bad wording on my part. I meant  "a method that expects to be given an
Intf1 or a method that expects to be given an Intf2."

I just don't think there's a really good solution, but as others have
pointed out, it fortunately doesn't arise very often.

Steve

Steve Horsley wrote:
> On Wed, 19 Jun 2002 23:12:14 +0100, "Coho (Richard Swain)"
> <vibron@krang.f9.co.uk> wrote:
> 
[snip]


>>and within that if you need to get hold of the other interface just do
>>
>>   Intf2 f2 = ((ThingThatDoesIntf1AndIntf2)fi).getIntf2();
>>

Er. Many apologies. After having a second look this cast wouldn't work, 
you would have to have the original object not its facet.
Sorry :-(


[snip]

> 
> Steve



-- 
http://www.krang.f9.co.uk

On Thu, 20 Jun 2002 13:01:31 -0400, Tris Orendorff wrote:

>> What's the problem with the above? In true multiple inheritance, where
>> you're inheriting multiple _implementations_, the diamond-of-death
>> occurs where you're not sure which _inherited_ implementation to invoke
>> first, or whether it's desirable to invoke one first. With Java, you
>> have multiple inheritance on at the _interface_ level, which alleviates
>> the diamond-of-death problem: you only have one inherited
>> implementation on
> 
> I'm sorry.  What exactly is the "the diamond-of-death?"

In C++, you can have the following:

class Base
{
public:
    virtual void doFoo();
};

class Child1:public Base
{
public:
    void doFoo(); 
};

class Child2:public Base
{
public:
    void doFoo();
};

class Grandchild1:public Child1,Child2
{
public:
    void doFoo();
};

Child1 and Child2 inherited Base and override the dooFoo() method.
Grandchild1 inherits _both_ Child1 and Child2, and overrides doFoo().
Now, when Granchild1::doFoo() invokes the methods inherited, _which_ one
does it invoke first? That is the diamond-of-death, and is avoided by
Java's not allowing multiple inheritance of _implementations_. You no
longer have to decide which implementation you're inheriting to invoke
first, since you can only inherit _one_. 

HTH. =)

-- 
Darryl L. Pierce <mcpierce@databasix.com>
Visit the Infobahn Offramp <http://welcome.to/mcpierce>
"What do you care what other people think, Mr. Feynman?"

Steve Horsley wrote:
> 
> On Wed, 19 Jun 2002 23:12:14 +0100, "Coho (Richard Swain)"
> <vibron@krang.f9.co.uk> wrote:
> 
> >> almost need to create a new interface:
> >>
> >> interface ThingThatDoesIntf1AndIntf2 {
> >>     Intf1 getIntf1();
> >>     intf2 getIntf2();
> >> }
> >>
> >> Except that you can't even pass this object round to a method that
> >> expects to be given an Intf1 or an Intf2.
> >
> >But I don't see how using somekind of namespace resolution is
> >polymorphic either. i.e to specify which method to call you *have*
> >to specify the interface the method is on. IMHO getIntfN() does that
> >just as well as some kind of language trick.
> >
> Me neither. Perhaps the best approach is to use a convention like:
>     public void intf1_draw()...
>     public void intf2_draw()...
> but I don't think people are likely to adopt it.
> 
> >You are right about specifying a new interface, but I would hope that
> >practically all concrete classes are expressions of interfaces - to
> >which those two methods can be added.
> >
> >If a method takes a particular interface intf1 say you can always do
> >
> >theMethod( myclass.getIntf1() );
> >
> That's not too bad. Except that there's no way to get back from the
> Intf1 to the original myClass object. I'm not sure you should ever
> want to, but I still feel alienated by this somehow.
> 

You could do this if you really wanted to do.  What you'd have to do is
enhance all your interfaces with an extra method:

    Object getContainingObject();

and then implement it this way within the anonymous call:

    Intf1  getIntf1()
        {
        return new Intf1()
        {
            public void X()
            {
                intf1X();
            }
            public Object getContainingObject() {
                return <Name of Containing Class>.this;
            }
        };
    }

Admittedly not as easy as in a direct implementation, but it seems to work.

Wayne

I agree, but the original problem provided some very awkward constraints.

Darryl L. Pierce wrote:
> On Thu, 20 Jun 2002 19:51:14 -0400, Wayne Berke wrote:
> 
> 
>>>That's not too bad. Except that there's no way to get back from the
>>>Intf1 to the original myClass object. I'm not sure you should ever want
>>>to, but I still feel alienated by this somehow.
>>>
>>>
>>
>>You could do this if you really wanted to do.  What you'd have to do is
>>enhance all your interfaces with an extra method:
>>
>>    Object getContainingObject();
> 
> 
> Ah, jaysus, now the interface that you want implemented has to have
> specific knowledge of any object that _might_ be owner? This is truly
> getting to be spaghetti code now. Anything of the sort describe would
> sure get marked in code review as needing to be reimplemented. What
> you're describing shows a marked lack of design consideration.
> 



-- 
http://www.krang.f9.co.uk

What is the answer?

Darryl L. Pierce wrote:
> On Fri, 21 Jun 2002 09:44:37 -0400, Coho (Richard Swain) wrote:
> 
> 
>>I agree, but the original problem provided some very awkward
>>constraints.
> 
> 
> Perhaps. But, the answer is never to write unmaintainable or awkward code.
> 
-- 
http://www.krang.f9.co.uk

Coho (Richard Swain) wrote ...
> What is the answer?
> 

The answer is to pass the abstraction that represents the set of 
information that the method needs, and to declare the method to accept 
the set of information that it needs.  To complain about not being able 
to get back to the original interface is, essentially, complaining that 
you can't write a method declared to take one type parameter, and then 
have it access that data as a different type.  If the method needed to be 
able to treat the object as a MyClass, it should never have declared its 
parameter to be of type Intf1.

I honestly can't find a single reason that this is even a problem, aside 
from the fact that someone said that dropping any kind of information 
makes them feel "alienated".  Programming without ever dropping 
information is antithetical to abstraction, and it's not workable.

Chris Smith

But that doesn't address the original problem  - "How does one 
distinguish between methods that happen to have the same name on two 
different interfaces inherited by the implementation?"



Chris Smith wrote:
> Coho (Richard Swain) wrote ...
> 
>>What is the answer?
>>
> 
> 
> The answer is to pass the abstraction that represents the set of 
> information that the method needs, and to declare the method to accept 
> the set of information that it needs.  To complain about not being able 
> to get back to the original interface is, essentially, complaining that 
> you can't write a method declared to take one type parameter, and then 
> have it access that data as a different type.  If the method needed to be 
> able to treat the object as a MyClass, it should never have declared its 
> parameter to be of type Intf1.
> 
> I honestly can't find a single reason that this is even a problem, aside 
> from the fact that someone said that dropping any kind of information 
> makes them feel "alienated".  Programming without ever dropping 
> information is antithetical to abstraction, and it's not workable.
> 
> Chris Smith



-- 
http://www.krang.f9.co.uk

> > That's not too bad. Except that there's no way to get back from the
> > Intf1 to the original myClass object. I'm not sure you should ever
> > want to, but I still feel alienated by this somehow.
> >
>
> You could do this if you really wanted to do.  What you'd have to do is
> enhance all your interfaces with an extra method:
>
>     Object getContainingObject();
>
> and then implement it this way within the anonymous call:
>
>     Intf1  getIntf1()
>         {
>         return new Intf1()
>         {
>             public void X()
>             {
>                 intf1X();
>             }
>             public Object getContainingObject() {
>                 return <Name of Containing Class>.this;
>             }
>         };
>     }
>
> Admittedly not as easy as in a direct implementation, but it seems to
work.
>
> Wayne

This is one of the main differences between having one class implement all
the interfaces, and having the class delegate some or all of the interfaces
to inner classes. This "dislocation" might have unfortunate effects. Not
only can't you "get back" to the object, but you also can't get to any of
the other *interfaces* that that object is supposed to implement.

As usual I can't think of a good concrete example of why this would be a
problem. I guess a problem could arise if some method took an object
parameter and expected that object to implement more than one interface (ie
to be of a certain co-type). The object itself might use "facets", but the
calling method won't know that. All it would know is "here is an object, and
I expect it to implement these interfaces. I'll do some typecasting to the
interfaces I need".  Name-resolution of some sort would allow the *single*
object to implement all of the required interfaces.

This doesn't convince me, however, because it is much safer for that method
to state which interfaces it needs in its signature - unless, of course, it
is a third party method...

Basically I now think that the problems related to multiple interfaces are
more theoretical than real, and that you can find workarounds when you need
them. Still, it does annoy me that you would *have* to use such workarounds
in some cases.

By the way, does anyone know if there is a "base" interface type -
equivalent of Object? I don't believe there is, but just want to make sure.

Tristan.

Tristan Reeves wrote:
[snip]
> 
> By the way, does anyone know if there is a "base" interface type -
> equivalent of Object? I don't believe there is, but just want to make sure.
> 
> Tristan.
>  

There isn't but I'm not sure what benefit it would give?


-- 
http://www.krang.f9.co.uk

"Darryl L. Pierce" wrote:
> 
> On Thu, 20 Jun 2002 19:51:14 -0400, Wayne Berke wrote:
> 
> >> That's not too bad. Except that there's no way to get back from the
> >> Intf1 to the original myClass object. I'm not sure you should ever want
> >> to, but I still feel alienated by this somehow.
> >>
> >>
> > You could do this if you really wanted to do.  What you'd have to do is
> > enhance all your interfaces with an extra method:
> >
> >     Object getContainingObject();
> 
> Ah, jaysus, now the interface that you want implemented has to have
> specific knowledge of any object that _might_ be owner?

Not at all.  In fact the interfaces can even be pre-existing ones that
don't contain the additional method.  The bottom line is they only have
the specific knowledge if they need to have it.

> This is truly
> getting to be spaghetti code now.  Anything of the sort describe would
> sure get marked in code review as needing to be reimplemented. What
> you're describing shows a marked lack of design consideration.
> 

Considering that your "code review" is based on flawed assumptions and
simplistic reasoning, it's hard to take it too seriously.

By the way, this problem has a very well-defined specification:  given
the inherent limitations of Java, provide a means for a class to simulate
an is-a relationship with two mutually conflicting interfaces.  Do you have
any kind of solution yourself, or would you rather just stand on the
sidelines and criticize others?

Wayne

Not sure about the "given the inherent limitations of Java," bit :-)

Wayne Berke wrote:
[snip]
> By the way, this problem has a very well-defined specification:  given
> the inherent limitations of Java, provide a means for a class to simulate
> an is-a relationship with two mutually conflicting interfaces.  Do you have
> any kind of solution yourself, or would you rather just stand on the
> sidelines and criticize others?
> 
> Wayne



-- 
http://www.krang.f9.co.uk

"Coho (Richard Swain)" wrote:
> 
> Not sure about the "given the inherent limitations of Java," bit :-)
> 
> Wayne Berke wrote:
> [snip]
> > By the way, this problem has a very well-defined specification:  given
> > the inherent limitations of Java, provide a means for a class to simulate
> > an is-a relationship with two mutually conflicting interfaces.  Do you have
> > any kind of solution yourself, or would you rather just stand on the
> > sidelines and criticize others?
> >
> > Wayne
> 

It's already been shown that other languages such as Eiffel do not have
this limitation.

Wayne

I don't know Eiffel so I can't comment. What are the disadvantages of 
Eiffel that mean it hasn't taken off in the same way as Java?


Wayne Berke wrote:
> "Coho (Richard Swain)" wrote:
> 
>>Not sure about the "given the inherent limitations of Java," bit :-)
>>
>>Wayne Berke wrote:
>>[snip]
>>
>>>By the way, this problem has a very well-defined specification:  given
>>>the inherent limitations of Java, provide a means for a class to simulate
>>>an is-a relationship with two mutually conflicting interfaces.  Do you have
>>>any kind of solution yourself, or would you rather just stand on the
>>>sidelines and criticize others?
>>>
>>>Wayne
>>
> 
> It's already been shown that other languages such as Eiffel do not have
> this limitation.
> 
> Wayne



-- 
http://www.krang.f9.co.uk

"Coho (Richard Swain)" <vibron@krang.f9.co.uk> wrote in message
news:3D1432AC.70904@krang.f9.co.uk...
> Tristan Reeves wrote:
> [snip]
> >
> > By the way, does anyone know if there is a "base" interface type -
> > equivalent of Object? I don't believe there is, but just want to make
sure.
> >
> > Tristan.
> >
>
> There isn't but I'm not sure what benefit it would give?
>
Nothing, seeing that you can pass an interface reference to a method
requiring an Object parameter (which I didn't know when I posted my lat
message).
eg If I have method myMethod(Object o), and an interface MyInterface, and a
ref to a MyInterface (call it rMyInterface), then I can call
myMethod(rMyInterface).

This is quite strange, because clearly MyInterface does not "extend" Object
in any conventional way (this is true because you can't call Object methods
from an interface reference), and yet once the interface has been passed to
myMethod, it seems that I have access to the Object that is implementing the
interface - this seems possible too by a straight typecast to Object.

Doesn't this break encapsulation??

Tristan.

It doesn't break encapsulation, you only have limited access to the 
Object and if your implementation is not declared public (i.e it has 
package scope) then you cannot get to it via casting down the interface. 
Thus you are limited to calling only methods on the public interfaces 
(which is good)

Rich

Tristan Reeves wrote:


[snip]


> Nothing, seeing that you can pass an interface reference to a method
> requiring an Object parameter (which I didn't know when I posted my lat
> message).
> eg If I have method myMethod(Object o), and an interface MyInterface, and a
> ref to a MyInterface (call it rMyInterface), then I can call
> myMethod(rMyInterface).
> 
> This is quite strange, because clearly MyInterface does not "extend" Object
> in any conventional way (this is true because you can't call Object methods
> from an interface reference), and yet once the interface has been passed to
> myMethod, it seems that I have access to the Object that is implementing the
> interface - this seems possible too by a straight typecast to Object.
> 
> Doesn't this break encapsulation??
> 
> Tristan.
> 
> 



-- 
http://www.krang.f9.co.uk

Tristan Reeves wrote:
> 
> This is quite strange, because clearly MyInterface does not "extend" Object
> in any conventional way (this is true because you can't call Object methods
> from an interface reference), and yet once the interface has been passed to
> myMethod, it seems that I have access to the Object that is implementing the
> interface - this seems possible too by a straight typecast to Object.

Actually, you can call Object methods on an interface reference, anywhere.

Basically, an interface reference contains either null or the object of some class, and 
all classes inherit from Object (except Object ... blah, blah).

So in,

public interface MyInterface { boolean equals(Object obj); }

The method declaration is redundant.

> Doesn't this break encapsulation??

I'm not sure why it would. However, it is a subtle quirk in Java.

-- 
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)

"Coho (Richard Swain)" wrote:
> 
> I don't know Eiffel so I can't comment. What are the disadvantages of
> Eiffel that mean it hasn't taken off in the same way as Java?

Perhaps it has never had a mega-company hyping it in the marketplace
and pushing out library after library.

yeh. I guess so.

Carl Gay wrote:
> "Coho (Richard Swain)" wrote:
> 
>>I don't know Eiffel so I can't comment. What are the disadvantages of
>>Eiffel that mean it hasn't taken off in the same way as Java?
> 
> 
> Perhaps it has never had a mega-company hyping it in the marketplace
> and pushing out library after library.



-- 
http://www.krang.f9.co.uk

Carl Gay wrote:

> Perhaps it has never had a mega-company hyping it in the marketplace
> and pushing out library after library.

That, and Meyer never had the good sense to make the documentation and a 
good development environment available for free. That at least is what 
stopped me from learning Eiffel.

-- 
Ben Z. Tels
bzt@bentels.dyndns.org
optimusb@stack.nl
http://www.stack.nl/~optimusb/
UIN:2474460

"The Earth is the cradle of the mind, but one cannot stay in the cradle
 forever."
                                        --Tsiolkovsky