In article <e20j3q$6lu$1@digitaldaemon.com>, Chris Nicholson-Sauls says...
>Here you lose encapsulation

Yes. But my suggestion does not work anyway, because CA and CB must reimplement the interfaces. Sorry.

Ryan Steen wrote:
> In article <e1vci0$1luu$1@digitaldaemon.com>, Lionello Lunesu says...
> 
>>They are completely unrelated.
>>Now what? Redesign the whole app and make multiple classes?
> 
> 
> Yes. Such design is flawed: to implement two completely unrelated interfaces in
> one single class.
> 
> 

// ABC inc.'s  DB lib (closed source lib)
interface DatabaseItemInterface
{
	...
	int get(); // load the data from the DB into the object, return something
	...
}


// XYZ corp.'s finance framework (closed source lib)
interface PerchaseRequest
{
	...
	int get();	// return the PO number for this item
	...	
}


// now, implement a finance database

Chris Nicholson-Sauls wrote:
> Ryan Steen wrote:
> 
>> In article <e1vlnb$226i$1@digitaldaemon.com>, Lionello Lunesu says...
>>
>>> IA might be an interface for the output/GUI and IB for the input.
>>
>>
>>
>> Yes, but what might cause the need to have the implementation in one class?
>>
>> And if there is really a need what hinders a virtual split of that implenting
>> class?
>>
>> IA --> CA <-- C --> CB <-- IB
>>
>> where --> and <-- denote inheretance?
> 
> Here you lose encapsulation, wherein you are basically having to create a C, then ask it for its CA and later for its CB, and the CA/CB classes (inner classes, maybe?) have to know their parent object and ask it for the real data and behaviors.  Ew, ew, ew. 

I fully agree.

>(Although at least inner 
> classes won't need the parent pointer,

yes but only because its already hidden in there by the compiler

> once we settle on some kind of
> 'parent' or 'outer' keyword.)
> 
> -- Chris Nicholson-Sauls

In article <e212nr$o5p$1@digitaldaemon.com>, BCS says...

>interface DatabaseItemInterface
>interface PerchaseRequest
>// now, implement a finance database

I do not understand this exercise. There are two closed source libs for which I have to provide the implementation?

If there are no more constraints, then it is possible to write classes which implement the two interfacec by wrapping the appropriate functions from the main application, the finance database.

But I already said it elsewhere, D would be better off with some features for renaming or aliasing interface content as well as interfaces themselves.

In article <e219lb$1193$1@digitaldaemon.com>, Ryan Steen says...
>
>In article <e212nr$o5p$1@digitaldaemon.com>, BCS says...
>
>>interface DatabaseItemInterface
>>interface PerchaseRequest
>>// now, implement a finance database
>
>I do not understand this exercise. There are two closed source libs for which I have to provide the implementation?

Make a database item class using the database provided interface that can be used by the finance lib (e.i. implements the finance interface).

The need for the interfaces comes from the need for library functions to handle the objects. Inside of the libs the "get" functions will be called using the interfaces.

>
>If there are no more constraints, then it is possible to write classes which implement the two interfacec by wrapping the appropriate functions from the
> main application, the finance database.

I'm not sure what you are saying?? Something like this (extra classes and objects) has bean suggested but it looks really messy to me.

>
>But I already said it elsewhere, D would be better off with some features for renaming or aliasing interface content as well as interfaces themselves.
>

Yes, this is exactly what I am suggesting. I have already outlined my suggested syntax elsewhere.

Chris Nicholson-Sauls wrote:
> Lionello Lunesu wrote:
>> #class Command : IResult, IResultRow {    // handle wrapper
> ...
>> #    int IResult.opApply( int delegate(inout IResultRow) dg );
> ...
>> #    int IResultRow.opApply( int delegate(inout IResultField) dg );
>> #}
> 
> I actually rather like this syntax.  When I first started reading your post, this was precisely what I thought of as a possible general purpose solution.  The difficulty I see is in how to select which to use at call-time.  In your case, I see you use a simple `cast(Interface) object` to do so, which seems fair enough... but might there be another way to do the selection in simpler expressions?
> 
> # class Foo : IA, IB { ... } // IA and IB declare: int get();
> #
> # Foo obj = new Foo;
> #
> # // call IA.get()... ew
> # (cast(IA) obj).get();
> #
> # // call IB.get()... eh
> # obj.get@IB();
> # // or
> # obj@IB.get();
> #
> # // call IA.get()... erm
> # obj.IA::get();
> 
> Just thinking.
> 
> -- Chris Nicholson-Sauls

Even when calling, I'd pick the "IB.get" syntax:

#class C : IA, IB {
#  int IA.get() {..}
#  int IB.get() {..}
#}

#void main() {
#  C c = new C;
#//  c.get();//error, ambiguity
#  c.IA.get();//OK, calls IA.get
#  c.IB.get();//OK, calls IB.get
#}

But there's probably some syntax parsing problem I know nothing about.

L.

In article <e21vvd$1sv1$1@digitaldaemon.com>, Lionello Lunesu says...

>#void main() {
>#  C c = new C;
>#//  c.get();//error, ambiguity
>#  c.IA.get();//OK, calls IA.get
>#  c.IB.get();//OK, calls IB.get
>#}

This example seems somehow flawed.

Interfaces are in the role of assuring access to some and denying access to some other public features of the implementation, don't they?

But if one has full access to the implementation as above, then their denials are ineffective. Therefore this cannot be the usual case.