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.
> 
> 

Yeah, if you implement completely unrelated interfaces in one class .. you only have yourself to blame.

In article <e1vbp8$1lcq$1@digitaldaemon.com>, Lionello Lunesu says...

>So the problem in the original post still applies to opIndex and opCall.

Only if the formal parameter lists stay the same. Is it a good design not to have typedef'ed subtypes for fieldnames and parameternames, rowindex and columnindex?

Ryan Steen wrote:
> In article <e1vbp8$1lcq$1@digitaldaemon.com>, Lionello Lunesu says...
> 
>> So the problem in the original post still applies to opIndex and opCall.
> 
> Only if the formal parameter lists stay the same. Is it a good design not to
> have typedef'ed subtypes for fieldnames and parameternames, rowindex and
> columnindex?
> 
> 

Nice idea!

#typedef uint field_no;
#typedef uint param_no;

#interface IA {
#	char[] opIndex(param_no);
#}

#interface IB {
#	char[] opIndex(field_no);
#}

#class C : IA, IB {
#	char[] opIndex(param_no p) { return "param"; }
#	char[] opIndex(field_no p) { return "field"; }
#}

#void main() {
#	C c = new C;
#	IA ia = cast(IA)c;
#	writefln( "ia[2]=",ia[2]);
#	IB ib = cast(IB)c;
#	writefln( "ib[2]=",ib[2]);
#}

Excellent, really... I think I'm in love...

L.

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.
> 
> 

I don't agree. The interfaces might be unrelated, but they can still both apply to the class needing them. IA might be an interface for the output/GUI and IB for the input.

L.

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?

In article <e1vlef$21vv$1@digitaldaemon.com>, Lionello Lunesu says...
>#	IA ia = cast(IA)c;
>#	IB ib = cast(IB)c;

Those casts are superfluous and dangerous.

Ryan Steen wrote:
> In article <e1vlef$21vv$1@digitaldaemon.com>, Lionello Lunesu says...
>> #	IA ia = cast(IA)c;
>> #	IB ib = cast(IB)c;
> 
> Those casts are superfluous and dangerous.
> 
> 

You're right. I first typed the mail and included the casts for clarity, and only later made a source file out of it.

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?
> 
> 

Can't inherit from 2 classes, only interfaces ;)

L.

In article <e1vroh$2805$2@digitaldaemon.com>, Lionello Lunesu says...

>Can't inherit from 2 classes, only interfaces ;)

Correct. But I do not remember a request, that one has to inheret vom class C splitted into CA and CB.

The implementation is shielded by the interfaces, isn't it?

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. (Although at least inner classes won't need the parent pointer, once we settle on some kind of 'parent' or 'outer' keyword.)

-- Chris Nicholson-Sauls