Re: Interface/Implementation (was Re: Design by Contract)

[Owen Fellows <ofellows@calfp.co.uk>]

Marc Wachowitz wrote:

> This is based on the Eiffel philosophy that every computation must be based
> on a method invocation for some object, and that independent variables or
> routines would be bad. Even the creation methods must be called in relation
> to an already created instance. The work-around (in my view - Eiffel fans
> might praise it as something logical) for library-functions is to have clients
> inherit from some class (or use other quite absurd tricks, based on classes
> without fields) to get at something like mathematical functions which do in
> fact only depend on their arguments, not on any "receiver". Thus the use of a
> routine library tends to be modeled as inheriting from a class providing them.
> 
> (To Eiffel fans: Yes, I've read Bertrand Meyer's arguments for a "pure" object
> oriented view, where classes are the only modules and where there aren't any
> non-instance-related routines. Having pondered these things for some time now,
> I don't agree at all, and prefer having non-class modules and some routines
> which aren't related to any instances.)

Originally I had this view too. But after some heavy use of Eiffel, and
some 
thinking about the problem I have come to the conclusion that it isn't a
problem.

The solution would be to have an extra section that is implemented in
the same
was as 'inherit'. If we call it 'use', then if you wanted access to
mathematical
functions such as sin, cosine then you would 'use' mathematician.
Internally
there would be no difference in implementation. By default the 'use'd
class
would be exported to {NONE}.

This prevents someone have a class A that 'use's MATHEMATICIAN using an
instance
of a to get access to sin, cosine etc.

eg.

	a.sin (10)

But it it more likely that you just inherit MATHEMATICIAN somewhere in
your
heirarchy to save on typing.

You can prevent the above with just inheriting by exporting to {NONE},
but I
have found in practice that this isn't a problem as if you don't have
access
to sin without using the form in the example, people just inherit
MATHEMATICIAN.

So, my argument would be what do you gain my adding something like
'uses'?
Not much.

What do you lose by not having it?
Not a lot.

Having the same implementation as inherits is a hint that it probably is
inherits!

Most people have a problem with this because of the inheirtance
corresponds to 
is-a.

In practice we have marked which classes are used for facility
inheritance by
choosing names for the classes that make sense, and by placing them at
the end
of the inheritance clause.

nickle@calfp.co.uk

Nick, via Owen Fellows account