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

[mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]

"John G. Volan" <johnv@ac3i.dseg.ti.com> wrote:
> Eiffel doesn't care about the order in which things are declared, but it
> also lacks this notion of elaboration order.  So how does it handle
> intializing classwide globals?  I seem to recall something about "once"
> methods -- routines that get executed just once, the first time they are
> called.  The results are cached, and all subsequent calls just return
> the cached results.  Supposedly you can initialize classwide globals
> inside such methods.  Do I have that right?

There aren't any classwide (or other) "global variables" in the usual sense,
only once-methods. The cached result of a once-method acts as a kind of global
object; i.e. if you want a true "variable" to which you can assign later, you
use a once-method containing (directly or indirectly) a field which acts as
your variable; if you do only need the initial value again and again, you can
use it directly as result of the once-method. Note that a once-method, as any
other method in Eiffel, has to be invoked on some instance of its class, or
any of its subclasses.

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

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>