Getting Ready

Tue Mar 1 19:58:44 UTC 2005

[From the salutation, I think Trygve meant to CC this list.
Here's his summary of BabyUML...]

>Date: Tue, 01 Mar 2005 10:16:31 +0100
>To: Dan Ingalls <Dan at SqueakLand.org>
>From: Trygve Reenskaug <trygver at ifi.uio.no>
>Subject: Re: Getting Ready
>
>Greetings, modulers
>
>Your work is really exiting and highly relevant to what I am trying 
>to do. I expect to build on the emerging modules by encorporating 
>them into my components. It could even be that my components are 
>relevant to the modules effort (happy thought!).
>
>I am working on a BabyUML report and hope to release a first draft 
>in a few weeks. Here are some main points:
>
>* I need a high level programming language/environment for systems of objects.
>* I need a stored program object computer (like Smalltalk/Squeak).
>* I think and work in terms of systems of interacting objects,
>   classes are also objects in my descriptions.
>* Object (sub)systems are encapsulated in components that are special objects.
>* Components are characterized by their provided and required interfaces.
>* A component appears as a black box object in its environment,
>   but can be opened up to reveal its internals.
>* Components are connected by links to other components/objects
>   that use the required and supply the provided interfaces
>* A component can encapsulate objects of any kind;
>   typically both application and class objects.
>* Generalization/specialization between components is under study;
>   the starting point is the UML 2.0 merge operation.
>
>The main purpose of the component is to divide and conquer. It could 
>also be a unit of security/privacy and of persistence and reuse.
>
>The regular ST class with its metaclass siamese twin feels 
>obfuscating in this context. I want the class objects to be treated 
>and understood as regular objects that are visible parts of my 
>system if I need to see them; I will then probably see them as 
>factory objects.
>
>I am creating a new metaclass architecture:
>- BMetaMetaclass is the mother of all classes.
>- BMetaSimpleclass is the grandmother of regular objects
>   (and the mother of the regular classes).
>- BMetaComponent is the grandmother of the components
>- Each metaclass has its own IDE
>   and the high level program description,
>   possibly including graphics, IS the program
>- The new objects and components interact seamlessly
>   with regular Squeak objects
>
>More later
>--Trygve
>
>At 08:11 01.03.2005, you wrote:
>
>>Folks -
>>
>>First of all, special thanks to those of you who took the time 
>>either to write a sort of position paper, or to fill out one of the 
>>summaries.  This really makes a difference.  It's exciting to 
>>embark on this project with such a knowledgeable crew.
>>
>>That said, I want to get the entries for Naiads and Islands filled 
>>out, and I'm hoping to get something on Universes as well, before 
>>we really blast off.  Craig, Andreas, and Lex, if you are 
>>listening, would you be willing to take a crack at these?  Anyone 
>>else?  See the New Modules page,
>>
>>	  http://minnow.cc.gatech.edu/squeak/5608
>>
>>
>>Meantime, here are some appetizers to get you ready for the main course...
>>
>>Think about a little PDA with ROM and RAM.  Suppose we blew the 
>>squeak image in to the ROM.  Could we run with it in ROM?  When we 
>>wanted to save, could we only save the differences from the ROM? 
>>If we started it up again, and made some more changes, could we 
>>just save those changes? What do these incremental snapshots 
>>suggest about modules?
>>
>>Consider Packages and Projects.  We might well open a new project, 
>>build a package, and store it as a project.  Or as a package. 
>>Compare and contrast these two modes of use, in particular noting 
>>how they might use the same underlying unit of modularity, and 
>>further noting in what other aspects they differ.
>>
>>Imagine a change to the VM which would allow message lookup to be 
>>intercepted.  If we are writing some application and want to add a 
>>few methods to class String, then we put them in a StringExtensions 
>>class in our package (sometimes called a virtual class).  A little 
>>table in the VM notes this and, when a message is looked up in 
>>class String, it is first looked up in StringExtensions.  Things 
>>may go a little bit slowly on the first lookup but then, of course, 
>>the method goes into the cache and there is no performance penalty. 
>>But look -- we have not modified class String at all.  Time to 
>>uninstall?  Zero.
>>
>>Now imagine that the VM can have multiple method caches, one per, 
>>um, per process?  per module?  Think about it.  And when you have 
>>figured it out, note that this system could run simultaneous 
>>multiple projects with conflicting changes to root classes with no 
>>performance degradation.
>>
>>Think about an image nicely partitioned into lots of little 
>>segments corresponding to different modules.  Might it make sense 
>>to garbage collect them separately?  And what about other aspects 
>>of storage management?  Supposing we are concerned about security, 
>>and someone attacks the system by consuming more and more storage. 
>>How do we catch that?  How do we make sure that it only affects the 
>>requestor, and not the rest of the system?
>>
>>More later
>>
>>	- Dan
>>
>
>--
>
>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/modules/attachments/20050301/f104ddf8/attachment.html