Path: news.daimi.aau.dk!rws
From: rws@daimi.aau.dk (Rene Wenzel Schmidt)
Newsgroups: comp.lang.beta
Subject: Re: unusual inner
Date: 24 Jul 1995 10:04:21 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 161
Message-ID: <3uvr75$5e3@belfort.daimi.aau.dk>
References: <3ulin4$h07@rs18.hrz.th-darmstadt.de>
NNTP-Posting-Host: fraxinus.daimi.aau.dk

Thus spake kuehne@sun46.isa.informatik.th-darmstadt.de (Thomas Kuehne):

>I read the FAQ, an introductory script on BETA, and roughly follow the
>discussions on comp.lang.beta, but I never encountered an explanation to
>the unusual approach of refinement with 'inner'.
>
>Any other OO language I know (maybe SIMULA is an execption?) allows
>to reuse the code of the superclass, that is:
>Old code maybe freely inserted in new code.
>BETA does this upside-down: 
>New code is inserted (at exactly one place) into old code.
>This is akin to higher-order functions in functional
>programming languages.
>
>Doesn't this approach hamper unexpected reuse?
>As far as I can judge the situation, a BETA program is not extendible
>
> [stuff deleted]
>
>However, I wonder if the BETA scheme isn't a bit to strict in practice.
>
>I'd be grateful for experiences with this strict scheme and for
>rationals that led to this language design.
>
>Best Regards,
>
>	Thomas

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.

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.

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

A Window system typically defines a class  'Window' which
defines the basic functionality of a window. To use it,
the programmer first has to execute some set-up code to open
it, and afterwards it has to execute a close operation.

This can easily be expressed in BETA by using INNER:

Window:
(#
   ....
do
   <open window and display it on the screen>
   INNER;
   <remove window from the screen>
#);

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. 

Another typically usage of INNER is to provide iteration-functions
for data-structures. A standard way of doing that in BETA is
to providing a scan-method that executes INNER for each element
in the list.

MyList:
(#
   element:<object; (* element type. A virtual which can be further
                       bound in a subclass  *)

   list: [10] ^element; (* We store the elements in an array *)

   scan:  
    (# current: ^element;
     do
       (for i: list.range repeat
          list[i][]->current[];
          INNER;
       for);
    #);

   ....
#);

In this way all control-structures are factored out of the main
program, and put in the container classes. A program that iterates
over the elements in a MyList has a statement like this:

   aMyList.scan(# do current.print; #);

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;
   

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. However, designing an extensible
framework in BETA is not simpler nor harder than designing an
extensible framework in, for example, C++. It takes a few design
iterations to figure out the best design.

I have written a lot of code in C++, and have just recently converted
to BETA. It is my experience that it is fairly easy to get used to
BETA's way of doing things. When you are designing classes in BETA
you are forced to think about how they can be extended in a fairly
direct manner, i.e., INNER = extensible point. Where as in C++ 
extensibility is not at a certain point, but is how a number of 
functions interoperate (e.g., first, next). 

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

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.  This
is in accordance to the 'Design Patterns' book, which advocates a
programming methodology where class hierarchies are shallow, and
functionality is brought into a class as components, not by
inheritance.

Hope this helps,

/Rene

----
Rene Wenzel Schmidt			       Fax: +45 8942 3255
Department of Computer Science		     Phone: +45 8942 3257	 
University of Aarhus	 		  Email: rws@daimi.aau.dk
8000 Aarhus C, Denmark	        WWW: http://www.daimi.aau.dk/~rws
-----------------------------------------------------------------
ORIGIN '~beta/guienv/v1.2/guienv' ---program:descriptor--- guienv
(# w:@window(# open::(# do 'Hello World'->title #)#) do w.open #)