[fpc-pascal] "is"

[Thomas Schatzl]

Hello,

Michael Van Canneyt schrieb:
> 
> On Thu, 7 Apr 2005, Thomas Schatzl wrote:
> 
>>
>>Summing MI with interfaces up:
>>- interfaces are only specifications, so there is no clash of implementations
>>- they neither have some initialization, so there's no problem about
>>constructing the instance either
>>- they provide means to model your world naturally
> 
> All this is nice, but it boils down to: MI for interfaces is shorthand notation. 
> No more, no less. It introduces no added value (other than notational) or 
> functionality.

You suggest that you simply treat the interfaces seperately and use 
clever single inheritance to simulate all that stuff by clever thought 
out checks.

In short: that's plain stupid (Please forgive me for that and please 
tell me that you meant something else).

Long version: it works if you're a really quick typist:

- you add lots of tiny mini-interfaces (actually _all_ interfaces which 
can be reached by that particular root node) to the list of implemented 
interfaces. Bad. Obsfucating code. What was the idea with inheritance 
again? Updating all that stuff when changing the hierarchy is hopefully 
done magically.
- regarding checks: if you change the hierarchy, you need to revisit all 
of your checks in the code whether they are reflected properly in the 
hierarchy. Do you really believe anyone will check and update a few 
hundred kb of code with tons of such checks, and test them all again?
- additionally, to be truely equal, all ancestors must manually 
aggregate all methods of child interfaces (otherwise you don't get the 
same functionality, look at the eat_just_something() example again). 
Changing the hierarchy comes to my mind again...
- you can optimize (e.g. so that you don't need to aggregate method 
names by hand) the hierarchy manually by defining single inheritance 
paths through the MI hierarchy (for every leaf node one, additional if 
there are diamond shapes in the hierarchy). But this leads to the 
problem that you actually need additional interface names 
"IJumpingMouseEatsEverythingMeatEaterPath" and 
"IJumpingMouseEatsEverythingPlantEaterPath" are _really_ descriptive, 
don't you think too? Wasn't it you who was complaining about good naming...?
What about hierarchy change again?
- you might need additional paths for the other examples to work 
(stopped counting here, numbers got too high).

This may work for a model hierarchy of five interfaces in total (and 
even then you do not do it that way).
Actually already really small OO-models easily have over thirty 
interfaces with all kinds of inheritance relations. Larger ones I know 
have a few hundred (e.g. CWM, MOF, UML).

Note to myself: I should give "real world" models as examples next time, 
not a carefully cleaned up one... people might start thinking that the 
problem is exactly like this, only with changed names.

> Where IC would simply be IA and IB conmbined. In IC, you hide what actually is.
> (the names are not always as descriptive as in your example.)

This is not a problem of MI-inherited interfaces, but a problem of the
programmer. You can do bad naming everywhere and anytime. It's simply 
the designer's job to do this properly, a good design includes good naming.
Btw, interface MI actually requires exactly the same amount or less 
names, for every interface exactly one (because otherwise you won't get 
the same functionality).

[Btw. same argument applies for single inheritance, every additional
level "hides" the methods the ancestor implements in the same way. Is 
single inheritance bad because of that now?]

 > I find it more clear to have
 > if  (A is IA) and (A is IB) then
 >   ..
 > Instead of
 >
 > If (A is IC) then
 >   ..

> If you need to check for IA and IB regularly in your code, then it is easy to write a 
> general-purpose function
> 
> Function SupportsInterfaces(A : TInterfacedObject; Interfaces : Array of Interface) : Boolean;
> 
> And then write
> 
> if SupportsInterfaces(A,[IA,IB]) then

 > Which is much more explicit about the properties you are actually
 > querying.

This is maybe more "explicit" for two interfaces, or maybe five. But 
please do _not_ tell me that for a hundred interface hierarchy (ok, you 
probably won't have to check all hundred at once).

The compiler won't help you here, because he does not know that IA and
IB have a logical connection and can't warn you that a (potentially) new 
ID is somehow related to IA and IB too and you missed it.

Outright unrealistic what you suggest.

> Also, if your component needs more than, say, 5 interfaces, then I think you need to do 
> some serious rethinking of your design. Even in OpenOffice (one of the more elaborate 
> collections of interfaces I've encountered so far) there are few objects with SO many 
> interfaces.

It's not the number of interfaces the object actually exposes, it's the 
number of interfaces and the hierarchy itself which requires the 
"shorthand notation".

I don't know OOo code, or what particular part of the code you refer to,
but I think I am able to counter your argument anyway:

What I know for sure is that in the Java-world (and likely similar in
the .NET world) interface MI is commonly used (even in the API). See the 
web, grab some projects and see (remember, the _number_ of interfaces in 
the hierarchy is relevant here, not what's actually exposed to the user).

If you refer to the C++ code: your observation is quite easily
explained, COM-interfaces don't allow interface MI so you will never get
a high *interface* count there (not even C programmers are that stupid).
Additionally C++ doesn't require interface MI (or interfaces in this
sense) at all, it already has implementation MI which is more powerful.
So the programmers following KIS only exactly export the COM-ones which
you can see and not a single more.
So an indicator for possible application of MI in C++ code is the amount
of implementation MI usage; I know for sure that this is generally quite
high... exactly to have a good model, and cut down code size to 
reasonable levels.
If you want to get a feeling of how much MI is actually used, just grab 
a medium sized C++ library.

Seems like the Java, .NET and C++ community "needs some serious
rethinking of their design" soon.
And I need a very fast typer right now. Michael, do you have some spare 
time?

>So, KIS (Keep it Simple) is the principle.

I'm currently asking myselves why I'm actually typing on a keyboard. I 
mean, punching cards were fine too... simple, easy, and actually working.

>Which is the computer variant of science's "Ockham's razor":
>
>''Pluralitas non est ponenda sine neccesitate'',
>which translates as
>``entities should not be multiplied unnecessarily''.
>
>The latin is rather fitting for computer language IMHO  :-)

Yes, yes, I get the idea and simply use another language for these 
things (if you don't want to apply for the typist position, that is ;-).

Regards,
   Thomas

*rofl*