"Environment tests"

Roel Wuyts Roel.Wuyts at ulb.ac.be
Wed Nov 5 10:07:33 UTC 2003


Hi Trygve,

interesting - let's see if I get it: inheritance just offers us a  
fixed, out-of-the-box interface we can and have to use (subclassing,  
overriding, ...). And this low-level interface has lots of power - so  
it becomes hard to track what is going on when we see a subclass. With  
delegation we can and have to control the interface we need. So it  
fixes an API for all to use.

So no solution for the semantic changes going on between versions, but  
cleaner interfaces.



On Wednesday, Nov 5, 2003, at 10:52 Europe/Zurich, Trygve Reenskaug  
wrote:

> May be delegation is better than subclassing when the class library is  
> evolving?
> ----------------------------------------------------------------------- 
> ---------
>
> The root of the problem is, IMO, the very large surface area between  
> class library and its subclasses in some NewStuff. An evolving class  
> library will always be a problem, but almost impossible to tackle  
> properly when there is a lot of subclassing. Automated tests help.  
> Then somebody has to go through all tests for all available packages  
> whenever there is a new version of the library and arrange for a bug  
> fix when anything breaks. And what about interference between  
> NewStuff-1 and NewStuff-x?
>
> Being badly burnt, I have come to believe that subclassing often is  
> evil because of the large surface areas involved. An alternative seems  
> to be delegation. NewStuff classes will then defines facades to  
> instances of library classes (e.g. Morphs). We then at least will  
> declare the interfaces we use. Incidentally, it will also make us  
> aware of the interfaces we rely upon without knowing it. The library  
> could offer components with relatively stable external interfaces and  
> evolving internals. May be we should promote interfaces to become  
> first class citizens like in Java. (The current method categories are  
> grossly underused).
>
> An additional solution could be to provide bounded object spaces,  
> something of an object parallel to the UML 2.0 merge relation -- a  
> bounded object space with controlled visibility to other spaces. But  
> even that won't help when needed library functionality changes.
>
> --Trygve
>
>
> At 05.11.2003 08:32, you wrote:
>> Hi Guys,
>>
>> Here's a weird and somewhat OT thought that was triggered by a  
>> discussion I
>> had today. One of the things I am noticing when looking at SqueakMap  
>> (and my
>> use of it) over the last year is that many of the packages that are
>> available from SM tend to break in the face of later Squeak versions.  
>> What
>> happens? Effectively, these packages have been written under the  
>> assumptions
>> of a certain environment in which they exist (namely that of Squeak  
>> X.Y) and
>> if these assumptions are ever (even partially) invalidated they break.
>>
>> In the discussion I had today Alan (again) mentioned that one of the  
>> things
>> that could be done for making sure an object (or a package) can  
>> survive in
>> some environment is to model (at least some) of the assumptions about  
>> the
>> environment explicitly. We do this internally by, for example, using  
>> unit
>> tests for the package but typically we have no model whatsoever about  
>> our
>> environment. This is (at least I think so) an even larger problem for  
>> a
>> dynamically typed environment than it is for a statically typed  
>> environment.
>> In the statically typed environment you can at least be assured that  
>> the
>> compiler will do certain checks on your types (and messages) so  
>> unless the
>> semantics of some message (or type) changes you should be safe (in  
>> theory).
>>
>> What I'm curious about here is: Has anyone ever seen a (hopefully even
>> usable ;) approach to model "environmental assumptions"? Are there any
>> common rules/guidelines on which "environment tests" could be based?
>> Anything else in this area?
>>
>> Cheers,
>>   - Andreas
>
>
> -- 
>
> Trygve Reenskaug      mailto: trygver at ifi.uio.no
> Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
> N-0378 Oslo           Tel: (+47) 22 49 57 27
> Norway
>
>
>
Roel Wuyts                                                               
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de  
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                     
Belgique
Board Member of the European Smalltalk User Group: www.esug.org




More information about the Squeak-dev mailing list