"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3gfvi$1jia$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a3gbp0$1got$4@digitaldaemon.com...
>
> > It doesn't work because the compiler's name resolution hasn't parsed the inside of the class when it is trying to resolve the outside.
>
> So it should give an error message? 'cause it doesn't...

That, then, is a bug!

"Walter" <walter@digitalmars.com> wrote in message news:a3heol$1vvv$1@digitaldaemon.com...

> I didn't know those languages offered that. While it's possible to
implement
> that, is it really necessary to support it?

Yes. Because sometimes it's not you who define the interfaces. It might happen so that two =absolutely= different interfaces, from different vendors, have to be implemented - and they can potentially have name clashes, and you can't just change one of them that simply because it's not your code... so you need a way to different between those methods somehow.

So far all languages I've seen provide the interface.method form for this.

Pavel Minayev wrote:

> "Walter" <walter@digitalmars.com> wrote in message news:a3heol$1vvv$1@digitaldaemon.com...
>
> > I didn't know those languages offered that. While it's possible to
> implement
> > that, is it really necessary to support it?
>
> Yes. Because sometimes it's not you who define the interfaces. It might happen so that two =absolutely= different interfaces, from different vendors, have to be implemented - and they can potentially have name clashes, and you can't just change one of them that simply because it's not your code... so you need a way to different between those methods somehow.
>
> So far all languages I've seen provide the interface.method form for this.

I believe Java dealt with this same problem with their package naming scheme.

--

Paul Apostolik
    paul@arches.uga.edu
    parabolis@softhome.net


Command line arguments  --

main( int argc, char * * argv ) {
    if( argc == 1 ) { cout<<"It's a nice day."<<endl; }
    else { cout<<"Don't argue with me, it _is_ a nice day."<<endl; }
}

FYI:
As far as I remember, and I've checked in the VM spec, but can't find a real
answer,
in Java if two interfaces declare a function with the same signature (N.B.
Java VM's DO overload on return value, even though the language does not
support this feature)
and you implement BOTH, you only implement one mehtod and calls to that
method from either interface would got to the same method. so  if you have

interface IsRenderable { void draw(); }
interface HasPension { void draw(); }
class A implements IsRenderable, HasPension { void public draw()
 System.out.println("boo!");} }
class B

static void getPension(HasPension h) { h.draw(); }
}
class

static void showObj(IsRenderable r){ r.draw(); }
}
class test
{
       static void main( String[] argv ) {
        A a  = new A();
        B.getPension( a );
        C.showObj( a );
    }
}
well the jdk 1.0.2/1.1 VM did
and it compiles and runs under 1.3 fine.
in java an interface is just "I agree to implement a function with this
signature",nothing more.
and if you try
interface IsRenderable { void draw(); }
interface HasPension { int draw(); }
class A implements IsRenderable, HasPension

  public void draw() { System.out.println("boo!");}
  public int draw() { return 1; }
}
class B

static void getPension(HasPension h) { h.draw(); }
}
class

static void showObj(IsRenderable r) { r.draw(); }
}
class test
{
       static void main( String[] argv ) {
        A a  = new A();
        B.getPension( a );
        System.out.println( "and I get $" + C.showObj( a )+" pension!" );
    }
}
you can't do it unless you write a with in bytecode asm.
you can not do implement an interface that would cause overloading of the
return value

Mike.

"Paul Apostolik" <parabolis@softhome.net> wrote in message news:3C5CF999.868FAF41@softhome.net...
>
>
> Pavel Minayev wrote:
>
> > "Walter" <walter@digitalmars.com> wrote in message news:a3heol$1vvv$1@digitaldaemon.com...
> >
> > > I didn't know those languages offered that. While it's possible to
> > implement
> > > that, is it really necessary to support it?
> >
> > Yes. Because sometimes it's not you who define the interfaces. It might happen so that two =absolutely= different interfaces, from different vendors, have to be implemented - and they can potentially have name clashes, and you can't just change one of them that simply because it's not your code... so you need a way to different between those methods somehow.
> >
> > So far all languages I've seen provide the interface.method form for this.
>
> I believe Java dealt with this same problem with their package naming scheme.
>
> --
>
> Paul Apostolik
>     paul@arches.uga.edu
>     parabolis@softhome.net
>
>
> Command line arguments  --
>
> main( int argc, char * * argv ) {
>     if( argc == 1 ) { cout<<"It's a nice day."<<endl; }
>     else { cout<<"Don't argue with me, it _is_ a nice day."<<endl; }
> }
>
>

Yet Delphi and C# do differentiate.

"Walter" <walter@digitalmars.com> wrote in news:a3heol$1vvv$1@digitaldaemon.com:

> 
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3gm8e$1m2f$1@digitaldaemon.com...
>> "Walter" <walter@digitalmars.com> wrote in message news:a3gh3a$1k44$2@digitaldaemon.com...
>> > Your only option is to change the name on one of the interfaces.
>> Aren't you going to add some way to resolve this, like in C# or Delphi? Like this:
>>
>>     class foobar: foo, bar
>>     {
>>         void foo.baz() { ... }
>>         void bar.baz() { ... }
>>     }
> 
> I didn't know those languages offered that. While it's possible to implement that, is it really necessary to support it?
> 
> 

The way I see it a interface is a contract that says a class implements a certain set of functionality.  Just because two functions are named that same between two interfaces does not mean that serve that same purpose in both.

When I first looked at what you were talking about, I was with Walter...why do you need it?  However, I repent.  We do need to be able to provide separate implementations.

How do we define which of the baz() functions is foobar.baz()?  Or do we
have to call them as foobar.foo.baz() and foobar.bar.baz()???

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C5ECBF3.3270321C@deming-os.org...

> When I first looked at what you were talking about, I was with Walter...why do you need it?  However, I repent.  We do need to be able to provide separate implementations.

...because matching names doesn't mean matching purposes!

> How do we define which of the baz() functions is foobar.baz()?  Or do we
> have to call them as foobar.foo.baz() and foobar.bar.baz()???

Yes, exactly.

Pavel Minayev wrote:

> > How do we define which of the baz() functions is foobar.baz()?  Or do we
> > have to call them as foobar.foo.baz() and foobar.bar.baz()???
>
> Yes, exactly.

Exactly what?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C5F0184.8EFDD824@deming-os.org...
> Pavel Minayev wrote:
>
> > > How do we define which of the baz() functions is foobar.baz()?  Or do
we
> > > have to call them as foobar.foo.baz() and foobar.bar.baz()???
> >
> > Yes, exactly.
>
> Exactly what?

Use the qualifier. foobar.foo.baz() or foobar.bar.baz().