> Stef,
> I see from various postings that many Squeakers are doing very 
> important work by gradually restructuring the kernel of Squeak. In 
> short term, I would greatly appreciate a copy of your new namespace; 
> it could replace the hack I am using for BabyUML components.

Hi trygve

we will release soon a version. If you really need it fast we can put 
as guest on squeaksource. Let us know

>
> I hope the first BabyUML result will be ready for experimentors before 
> Xmas. The planned publication stages are:
>
>    1) An object reverse engineering tool. It helps me build a diagram 
> of interlinked objects existing in the image. This diagram complements 
> the class browsers because it helps me identify critical objects and 
> their relationships.
>
>    2) The new BabyUML instantiation architecture. 'Pete' is an 
> instance of BPerson. BPerson is an instance of BMetaclass. BMetaclass 
> is an instance of BMetaMetaclass. BMetaMetaclass is an instance of 
> itself. A class no longer has its private metaclass.
>
>    3) An object browser that lets me see and edit an object's state 
> and behavior. (The superclass structure being flattened)
>
>    4) A new metaclass: BMetacomponent is an instance of 
> BMetaMetaclass. An instance of a BMetacomponent is a component, an 
> object that encapsulates other objects. The component defines its 
> provided and required interfaces and has its own 'factory' object, 
> this is an object that creates the encapsulated objects and also 
> provides the services that are covered by the Squeak metaclasses. The 
> component also has its own namespace; that is the reason why I am 
> interested in trying your namespace class.
>
> My dream is that the work I am doing will complement what you people 
> are doing so that we may see a new, clean and transparent Squeak in 
> the not too distant future.
>
> Cheers
> --Trygve
>
>
> At 21.11.2004 21:13, you wrote:
>> Hi colin
>>
>> We have been recently working on refactoring SystemDictionary quite a 
>> lot :) and we have now a namespace class to deal with bindings in a 
>> nice and clean way. Our goal is to enable people willing to 
>> experiment with new kernel/new language to do it. So having a browser 
>> that does not consider Smalltalk as the only possible namespace is 
>> great.
>> As soon as 3.8 is out we will push a lot of fixes related to the 
>> refactoring of systemDictionary in the stream.
>> So OB will be a big player in the future :) because it would be nice 
>> to start to think using real package instead of category :)
>>
>> Stef
>>
>> On 20 nov. 04, at 17:41, Colin Putney wrote:
>>
>>> Still it seems to me that if we aren't going to actually use 
>>> multiple environments we ought to make the scoping hierarchy more 
>>> sensible. BTW, just in case the fact that we only have one 
>>> environment today is a tools issue, I've tried to make OmniBrowser 
>>> as environment-agnotistic as possible. It takes an environment as 
>>> the root of its node graph and asks classes for their environment 
>>> rather than referring to Smalltalk. IIRC, the one or two places 
>>> where this breaks down is when dealing with system navigation 
>>> (senders, implementers etc.) It would be nice to be able to do 
>>> something like [aClass environment navigator] rather than having a 
>>> single global navigator that is hardcoded to Smalltalk.
>
>
> -- 
>
> 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
>
>
>