Hi Adrian -

[Side note: If you feel this discussion is taking too much of your 
valuable time, then let's post-pone it up until we have something to 
look at].

Adrian Lienhard wrote:
> 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".

Well, that's some of the reasons. But there are really more than that. 
For one thing, the current situation reminds me a bit about the failed 
modules approach (a good idea; too few people understanding both concept 
and implementation; pressure to get things into "this" version; the need 
to deal with architecture, tools, support, integration at the same time; 
  no buying into the changes over a period of time...) and that lets me 
get very, very cautious. I would feel much better if we had an 
incremental path along which we can describe the different tradeoffs and 
make sure there are other people who can learn and understand the new 
architecture and its implementation.

Also, you need to consider those projects in the community, which really 
require a stable kernel. Realistically speaking, I don't see how a 
traits kernel could be as stable as the current kernel if it were 
choosen as the "default" kernel for 3.9 (that is based on my 
understanding of how many people who actually understand it, and how 
much time those people could probably spend on it). And if 3.9 ships 
with a kernel that's less robust than the prior versions, I think you 
may find that those projects don't adopt it, but rather wait until some 
later version is out. And when that happens, both loose - you loose 
because the users of such projects won't test your kernel, and the users 
of that project loose because they can't even try it. Contrary to which, 
if you have the option to load either one, both sides win: You gain more 
time to fix the issues and avoid a death march, and whoever wants to has 
a really easy way of trying it out.

> 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

Well, that may be true, but consider your wishes well. Because I think 
you *will* get swamped with bug reports (and complaints) that nobody but 
you can fix and if you don't fix 'em fast, you'll get quite a bit of 
frustration (you should read up on some of the treads in the late stages 
of the modules area to get a "feel" for the kind of issues you may have 
to deal with). Even more so if the tools don't work quite right yet. And 
in my experience, once people get frustrated that way, they won't look 
at it again for a loooong time (this happened with modules, too).

> - duplication: all upcoming changes to the traditional kernel have to  
> be done in parallel in the new kernel to keep it up to date

True, but if the kernel is available, it would allow people to write 
patches in a way that makes them work both ways. And I would claim that 
this is a great way of learning more about traits and how to make things 
happen in a traits kernel. It would raise some very necessary 
discussions that we haven't had simply because people don't dabble 
enough in the traits kernel.

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

Well, let's talk about it. In my experience there are always alternative 
ways of doing things and saying that "there is no other way" almost 
always means you don't want it no other way ;-) I at least would be 
happy to lend a helping hand and I think that doing this would be a very 
healthy exercise for all kernels now and future (e.g., abstracting 
responsibilities, putting them into the right places etc).

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

That is certainly true. But the real key question is: What about the 
next release? You're changing some of the most fundamental underpinnings 
of the system that has so far-reaching implications that I don't think 
even you really realize how much of the code base it affects. Even 
worse, at this point there isn't even anything resembling a release 
candidate so all of the arguments are pure theory (which is quite 
disturbing for me; it means we're actually betting on something that 
nobody has even seen in full yet)

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

I'm not sure I really understand what you are trying to say here. First, 
"going back to the earlier versions" seems a horrible idea if you're 
looking at it from the point of view of stability. If we are unsure if 
that stuff really works, then why bet a whole system on it? If we have 
doubts, _any_ doubts, shouldn't we be a bit more careful to begin with? 
(this is really why I am advocating a more staged process here)

Second, why is unloading important? Well, it's not important if the 
kernels can be choosen. It is *tremendously* important if you want to 
use some advanced facilities of 3.9 but have other code that relies on 
the metaclass kernel structure. For example, Tweak has some very deep 
ties into this architecture (which would be a prime reason not to go to 
3.9 if I cannot figure how to make this work in a reasonable time 
frame); I have development packages (PlusTools) which rely on the 
current metaclass architecture etc.

Thirdly, about whether there is any difference at all, well that remains 
to be seen, right? For example, will any of the browsers, any of the 
reflective tools, any of the class/code analysis tools continue to 
function? It's not just the class definition that matters here.

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

That sounds good to me and is definitely necessary. We should have 
something to talk about before we make any decisions.

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

I tried loading it from a 3.7 (full) image. Alternatively, if you could 
dig out that link I would greatly appreciate it.

Cheers,
   - Andreas