Xref: utzoo comp.object:3353 comp.lang.eiffel:1538 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!news.funet.fi!jyu.fi!sakkinen From: sakkinen@jyu.fi (Markku Sakkinen) Newsgroups: comp.object,comp.lang.eiffel Subject: Re: Unification: Class=Type=Module Message-ID: <1991Apr25.074758.6153@jyu.fi> Date: 25 Apr 91 07:47:58 GMT References: <1991Apr23.142800.12215@bony1.bony.com> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) Organization: University of Jyvaskyla, Finland Lines: 63 In article davis@barbes.ilog.fr (Harley Davis) writes: > >In article <1991Apr23.142800.12215@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes: > > One of the things I liked about "Object Oriented Software Construction" > by B. Meyer, was the idea that a class is both a type and a module. > ... I think this is essentially the "orthodox" object-oriented attitude in general. > ... > I am curious whether other people think about this, and whether such > "unification" has any disadvantages. > >For me, a module is a higher-level structuring tool than a class. A >module pulls together a set of classes, functions, methods, and local >data which form a coherent design unit. A class is just one of the >possible implementation choices for a module; not everything need be >tied to a class. This is approach taken by, for example, EuLisp and >Le-Lisp version 16. > >While classes could be identified with modules, I find that in real >cases this forces too fine-grained a separation on the implementation. >It is difficult to define a module containing an entire class >hierarchy with associated operations, all exported as a unit. > ... In conventional OOP, an entire class hierarchy is certainly not a unit or module. In fact, open-endedness for inheritance is perhaps _the_ strong point of OO reusability. Otherwise, I agree with Davis against the more orthodox view. Thus, the package/module facilities of e.g. Ada and Modula-2, when wisely used, are more versatile than the "one type at a time" approach of CLU (the original ADT language) and most OOPL's. Also, in typical OOPL's, every operation has exactly one "participant" object that is in a distinguished role: the owner or "self"; any other "participants" are considered arguments. I suggest that as many operations as possible should be defined _on_ classes instead of _in_ them, i.e. without a distinguished participant. On the other hand, there are situations which crave for more than one "owner" in an operation: just look at the unnatural way in which ordinary arithmetic operations are defined in Smalltalk. I have not read about any object-oriented language that would allow several owners in an operation (unless the specification language DisCo is counted). In the generic functions (multi-methods) of CLOS, the _selection_ of actual method(s) to be invoked can be based on more than one argument, but in the _execution_ there is only one "self". Apologies if I am repeating some of my earlier ramblings too much ... Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)