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:

Have you guys ever considered that, instead of doing open heart surgery 
on a conscious patient, e.g., reformulating core-classes while the 
system is running, you might as well evolve it sideways?

I got this idea a while ago when I got so pissed about some of the 
changes that have been done in 3.7 that I started looking for 
maintaining "my own metaclass hierarchy" in a way that would isolate me 
from being dependent on those changes and it turns out that this is 
surprisingly simple. All you need is a basic metaclass hierarchy, a 
classbuilder that allows you to insert new metaclasses (nothing you want 
to do casually, but in these cases it's really useful) a single 
recompilation after loading, and voila! There is your parallel class 
hierarchy functioning just as well as any other.

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.

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
>>
>>
> 
> 
>