comp.lang.ada
 help / color / mirror / Atom feed
From: Graham Perkins <gperkins@dmu.ac.uk>
Subject: Libraries in pure OO [was Interface/Implementation (was Re: Design by Contract)]
Date: 1997/09/16
Date: 1997-09-16T00:00:00+00:00	[thread overview]
Message-ID: <341EB0A2.131F@dmu.ac.uk> (raw)
In-Reply-To: 5vkfb2$f2p$2@trumpet.uni-mannheim.de


.. hope thread renaming helps rather than hinders.

How to get normal library effect from OO language?
Especially pure one such as Eiffel where there are
no modules (ie, "static" bits of the classes).

IMHO two very important things about libraries, 
regardless of whether you try to provide them 
with modules, classes, or whatever:

 (1) Use the library in client mode (because
     library designer hid stuff in order to
     reduce coupling and allow evolution).

 (2) System should have a single instance of
     the library (because multiple instances
     would simply waste space/time as they're
     indistinguishable).

Modular languages
-----------------
You can easily get both effects 1 and 2 above 
because a module (unit, package, whatever you
call it) has precisely those properties.

Hybrid languages
----------------
You can easily get both effects in hybrid
languages such as C++, Java, Smalltalk ;-))
since class doubles up as module. (part
of class generates 0,1, or more runtime
instances but another part of the class
describes a single runtime instance).  Though
to ensure (1) you should disallow creation
methods in your library class.

Pure class languages
--------------------
You don't have a module or a class-which-is
-also-a-module, but you still have ability
to program in client-supplier mode and create
single system-wide instances.  So you can still
ensure properties (1) and (2).  In Eiffel:

  a) put a once function in ANY (remember
     that ANY is a good place to put your
     per-project stuff).

  b) define an anthropomorphic class (eg
     MATHEMATICIAN) which provides access
     to library via once function.  Make sure
     library creation method is only visible
     to this accessor class.

These alternatives can be implemented in other
languages without much difficulty.

--------------------------

what about

   feature
     math : expanded BASIC_ROUTINES
     ...
     x := math.sqrt( y )

Yes I know it was rather neat to put expanded
library object wherever you want it, but that
relied on 
  - constructed value objects (bye bye Java
    and Smalltalk)
  - static binding for value objects (can't
    be sure in C++)
  - no attributes at all in the class
The last point in particular is a problem, since
it means that the client programmer is taking 
advantage of internals of the class.  Which isn't
safe clientship in my view.

Sorry if I'm stating the obvious, but I hadn't seen anyone
explaining an implementation approach in terms of usability
principles such as (1) and (2) above.




  parent reply	other threads:[~1997-09-16  0:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-15  0:00 Interface/Implementation (was Re: Design by Contract) Marc Wachowitz
1997-09-16  0:00 ` Owen Fellows
1997-09-16  0:00 ` Graham Perkins [this message]
1997-09-17  0:00   ` Libraries in pure OO [was Interface/Implementation (was Re: Design by Contract)] Franck Arnaud
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox