Hi Andreas

On Oct 24, 2005, at 1:41 AM, Andreas Raab wrote:

> Hi Adrian -
>
> Thanks for the update. I will admit that based on what you write  
> I'm not entirely sure what a realistic deadline for traits  
> integration may be (do you have one?). It looks like you're  
> probably several weeks away from a version that could be tested and  
> that testing will (given the complexity of the changes) likely take  
> another couple of months. Since I'm not sure it's worthwhile or  
> necessary to "hold still" for such a long time, so let me ask a  
> question:

Its not that the amount of remaining work is in the range of weeks or  
month, rather days - but as you might imagine, the problem is as  
usual the limited time I can spend on this project. What I planned to  
do is working two days within the next two weeks and I think I should  
have a first working version that can be loaded in current 3.9a. Also  
worth mentioning is that "standing still" would be necessary for the  
kernel package only (or even only Kernel-Classes).

[...]
>
> Why is this advantageous? Two reasons mostly: For one thing, it  
> allows people to load traits side-by-side with the existing class  
> kernel (and be able to unload it which I think would be a VERY  
> useful property) without the fear of breaking their formerly stable  
> system. I would also think that this approach would allow you guys  
> to push the core parts a lot earlier than otherwise possible - it  
> may not be enabled by default, but it allows people to play around,  
> fix any issues (like Monticello, browsers etc). And when the time  
> comes, all you do is to pull the big switch and turn everything  
> over to a traits metaclass hierarchy.

Interesting - thanks for sharing this.

I see, this would make it trivial to (i) not force people to use the  
new code and (ii) unload/get rid of traits (for whatever reason). And  
therefore, would put less pressure on the "traits-team".

On the other hand, I see some quite important drawbacks, that have to  
be considered:

- the new kernel would not be used/tested as much as if it was the  
primary 3.9a kernel
- duplication: all upcoming changes to the traditional kernel have to  
be done in parallel in the new kernel to keep it up to date
- the alternative metaclass hierarchy helps running with two class  
kernels at the same time, but it does not help with other changes  
that are needed to make the system smoothly work with traits, such as  
adaptation of the code browser, fileOut/in, debugger and such. These  
are not that big changes but I don't see how we would make that work  
for the new and for the old code at the same time.

So, I definitely see your arguments but I fear, that this will make  
it rather harder to get traits in, in the end. The new code will  
break here and there, but that's basically the idea of running in  
alpha mode, isn't it? Somebody who needs to depend on
a stable system, shouldn't use the alpha images either way.

In the worst case, if we should come to the conclusion that it just  
does not work or we have a better solution than traits or whatever,  
we can still go back to earlier MC versions of the modified packages  
and backport later introduced changes. That's not a one-click action  
and thus not an option for people that want to remove the stuff we  
added again. But I don't see why unloading is that important(?). If  
you don't want to use traits or even don't know about it, there's not  
much, if any at all, difference you would see compared with previous  
versions of Squeak.

So, what I suggest is, give me three weeks to produce a loadable  
version of traits in a current 3.9a image and then see how this works  
and what problems we run into. At this time we can decide whether we  
continue 3.9a with these changes or go for a split solution.

Cheers,
Adrian

BTW: you mentioned in another mail problems with loading traits as it  
is published on SM? Did you load in a 3.7 image? That has been  
working for quite a couple of people... if you want to look at the  
implementation, then I suggest to use Daniel's image he posted a link  
to some weeks ago. What Daniel and I have been doing since then was  
only bringing it up to date with 3.9a, and working on the bootstrapping.

>
> If you're interested in this, I've put you an example of such a  
> bootstrap up at Squeakmap:
>
> http://map1.squeakfoundation.org/sm/packagebyname/MetaclassBootstrap/
>
> which should load into any 3.8/3.9 image and will create the basic  
> kernel required to boostrap the new metaclass hierarchy. When it's  
> loaded, inspect any MyObject subclass and notice the variables foo,  
> bar, and baz in its class and Metaclass which were added by  
> MyBehavior (that's just to show that indeed, MyObject is defined by  
> the MyBehavior hierarchy). All subclasses of MyObject are created  
> as MyMetaclass instances and you can actually create new instances  
> with a specific metaclass by extending Class to take the metaclass  
> in question and pass it to MyClassBuilder[*]. You can see an  
> example of that in MyMetaclass class>>initialize which does the  
> initial bootstrap of changing MyObject from its regular metaclass  
> to MyMetaclass.
>
> So what this gives you is the ability to bootstrap a perfectly self- 
> contained class kernel which you can then hack to the best of your  
> abilities :-) Even better, you can convert that kernel between the  
> different metaclasses which can be quite advantageous when things  
> get too nasty.
>
> What do you think?
>
> Cheers,
>   - Andreas
>
> [*] For those interested, there is an interesting anomaly when you  
> add new metaclasses: It is necessary to change the meta class  
> inheritance, e.g., although "MyObject superclass == Object" it is  
> the case that "MyObject class superclass ~~ Object class" but  
> rather MyClass. Why is that? Because having a superclass implies  
> identical shape for the subclass and since our new metaclasses can  
> be completely different from the old ones (in the example, I added  
> foo, bar and baz) we cannot inherit from any but the same kind of  
> metaclass. This also implies that any non-inherited class methods  
> cannot be called; e.g., "MyObject windowColorSpecification" will  
> raise a DNU despite the fact that windowColorSpecification is  
> implemented in Object class (which MyObject class no longer  
> inherits from). Which really all just goes to say that if you do a  
> bootstrap you should probably do it completely, e.g., with a nil  
> subclass to avoid nasty surprises. But for experiments like we're  
> talking about here this is still very cool and useful :-)
>
> Adrian Lienhard wrote:
>
>> 1) The current work needed to bring traits to 3.9 is integrating  
>> the  relevant changes that were done in 3.8 and until now in 3.9.  
>> The  initial implementation was done in 3.7, thus, what we now  
>> have to do  (and Daniel and I partly already did that) is  
>> integrating changes.  This is not that trivial because for example  
>> methods were moved into  traits in the new kernel to avoid code  
>> duplication. However, to be  able to use MC's diffing, we did some  
>> tricks (flattening classes)  that help us in the process. What  
>> then remains is  the methods that  should actually be removed  
>> (e.g., because they were deprecated),  added (e.g., new behavior  
>> of the new kernel) and conflicting changes.  This is the next task  
>> that has to be done based on a fixed Kernel  version of 3.9a (this  
>> has to be fixed because else we just end up  redoing it again).  
>> This should also answer the question about waiting  for traits  
>> with further harvesting: it should be enough for us to  have the  
>> Kernel package frozen until our stuff gets in because this is  
>> where most of the changes are. So, harvesting in other packages  
>> is  ok.
>> 2) The next part of the story is doing the bootstrapping, that  
>> is,  having a set of versions that can be loaded in a specific  
>> order into  a current 3.9a image.
>> 3) When having finished with these two steps we should finally be   
>> able to load the new traits-aware kernel, and start doing  
>> remaining  cleanups (e.g., moving class extensions into correct  
>> packages),  adjustments (making the code browser and other UI  
>> stuff work with  traits) and testing/bugfixing.
>> 4) The other parts are the UI (Daniel worked on a new OB  
>> browser),  traits-aware MC and fileIn/Out (already exists but a  
>> review would be  good) etc.
>> I'm not sure if it really makes sense for step 1) and 2) to have  
>> help  because the coordination overhead is quite big. Currently  
>> Daniel does  not have time to help here, so I will do it in the  
>> next weeks.
>> But for 3) and 4), when we actually have something that can be  
>> loaded  in 3.9, help would very much be appreciated.
>> Daniel, anything to add what I forgot?
>> Adrian
>> On Oct 23, 2005, at 1:00 AM, Andreas Raab wrote:
>>
>>> Marcus Denker wrote:
>>>
>>>
>>>> Another problem: I directly sent you a mail that it will take a  
>>>> while
>>>>
>>>>
>>> > to integrate your changes. One of the reasons is that we can't  
>>> right
>>> > now update the image, another is that, as I said, we need to
>>> > carefully look into how these change interact with traits.
>>>
>>> Out of curiosity: What is the status of traits? What conflicts   
>>> exist and need to be addressed? Where can I have a look at the   
>>> current version to see what potential conflicts there are and  
>>> how  to work them out?
>>>
>>> For the records, I have of course tried to load the 3.7 traits   
>>> version from SqueakMap but to no avail - it takes about an hour   
>>> before it dies with an "error during install: PureBehavior   
>>> class>>compiledMethodAt:ifAbsent:". And when I try to open a   
>>> debugger I get repeated errors of the same sort so it's no good   
>>> even to try to understand what is going on here.
>>>
>>>
>>>
>>>> Why do we now need to rush everything? We managed to do nothing   
>>>> for 8  Months while waiting for 3.8, so why now suddenly the rush?
>>>>
>>>>
>>>
>>> How about "because we would all like to avoid such delays in the   
>>> future"? Is that good enough of a why? ;-)
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>>
>>>
>
>
>