Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!news.sprintlink.net!howland.reston.ans.net!Germany.EU.net!news.dfn.de!gina.zfn.uni-bremen.de!marvin.pc-labor.uni-bremen.de!news.uni-stuttgart.de!news.belwue.de!News.Uni-Marburg.DE!news.th-darmstadt.de!isa.informatik.th-darmstadt.de!kuehne
From: kuehne@sun46.isa.informatik.th-darmstadt.de (Thomas Kuehne)
Newsgroups: comp.lang.beta
Subject: Re: unusual inner
Date: 26 Jul 1995 10:07:29 GMT
Organization: TU Darmstadt, Praktische Informatik
Lines: 119
Distribution: world
Message-ID: <3v5451$12j2@rs18.hrz.th-darmstadt.de>
References: <3ulin4$h07@rs18.hrz.th-darmstadt.de> <3uvr75$5e3@belfort.daimi.aau.dk>
Reply-To: kuehne@isa.informatik.th-darmstadt.de
NNTP-Posting-Host: sun46.isa.informatik.th-darmstadt.de

In article <3uvr75$5e3@belfort.daimi.aau.dk>, rws@daimi.aau.dk (Rene Wenzel Schmidt) writes:

> BETA advocates a real-world modelling design philosophy where a class
> models a concept in the real world. Sub-classing (or specialisation
> in BETA terms) are then used to make more 'specialized' concepts. Hence,
> it is not possible to overwrite the behaviour of a class, only to
> specialize it though the INNER mechanism.

It appears that this means: If you got your design wrong, you'll
have to rework it from scratch. There is no way to use, possibly yet not
correctly designed, old code, to figure out new code.

To my knowledge, overriding behaviour is an important activity in
framework iteration. Only until the framework has been proven successful,
it is possible to get rid of this "white-box" reuse.



> Stated in more practical terms: A superclass can assure that certain
> pre- and post-conditions are always satisfied for its subclasses. This
> is a pretty useful thing.

Agreed. But it should be a voluntary not a mandantory concept.

 
> To better understand the INNER mechanism in BETA, lets look at two
> examples: A Window system and a container class. 

> [ ...]

> A C++ implementation would look something like this
> 
> class Window {
>   ...
> public:
>    void open();
>    void close();
> };
> 
> Where the programmer explicit has to call the open and close methods. 

No. 'open' and 'close' can be called from the create method of Window.

void Window::create() { open(); inner(); close(); }:

'inner' is defined by subclasses of Window.
The only thing that is different to BETA, is that you need a new
name for 'inner' in the Window-subclasses (Thanks to Daniel May 
for pointing this out). But it works alright.


> In a C++ implementations you are typically required to
> write an explicit for-loop in your code. Like this:
>   
>    Element *current;
>    for(current=aMyList.first(); current; current=aMyList.next()) 
>       current->print;

Again, although external iterators are more common in C++, you can
also apply the parameterization-by-inheritance scheme you used for
BETA. You can easily translate BETA's 'inner' to a method 'inner' in
C++, which is empty in the superclass and refined in the subclass.

Actually, this is how the Eiffel iteration libraries work.


> This is two examples of a typical use of INNER. Situations similar to
> these happens very often, and that is why it is indeed possible to
> write extensible programs in BETA.

I am not convinced. You did not adress the issue, when I want to
specialize a pattern which has no inner inside.


> Just to conclude this discussion of the INNER mechanism, people is
> often claiming that it prevents code reuse, for good and for worse.
> Code reuse in BETA is done by using objects as components:
> 
>   MyObjectWithCodeReuse:
>   (#
>       comp1: @SomeCodeINeed(# ... #);
>       comp2: @SomeCodeINeedToo(# ... #);
> 
>       ...
>   do
>     ...
>   #);

I don't feel it is time to conclude the discussion but you made
a very good point, by pointing out code reuse through components.

Thus, a common need for overriding has vanished, but the question
remains how to specialize patterns, that do not provide an 'inner'.
Or maybe the 'inner' is at the wrong place for your purposes?
Or different subpatterns need the inner at different places?
Im still puzzled.


> In BETA it is possible to specialize components, so using this
> structure it is possible to achieve the same effect as mix-in classes,
> but without actually making the class a subtype of the mix-in. 

Yes, that's good. But then, it is possible in any OO language, isn't it?
(Components could be specialized before using them so there is no need
 to specialize 'on the fly')

Regards,

	Thomas

+---------------------------------------------------------------------------+
| Thomas Kuehne                                                             |
| Institut fuer Systemarchitektur                                           |
| Fachgebiet praktische Informatik                       Tel.: 06151/165420 |
| Technische Universitaet Darmstadt                      Fax.: 06151/165472 |
| Magdalenenstr. 11c                  kuehne@isa.informatik.th-darmstadt.de |
| D-64289 Darmstadt       http://www.isa.informatik.th-darmstadt.de/~kuehne |
|                                                                           |
+---------------------------------------------------------------------------+