Jerome Peace wrote:
>
>> Matthew wrote:
>> I wrote a script that removes traits from a 3.9 or 3.8 image:
>> http://installer.pbwiki.org/UnloadTraits
>>
>> In an image with Installer (preferably LPF), do:
>> Installer install: 'UnloadTraits'
>> <...>
>>     
>
> Ok. Then what does this give you?
>
>   
It gives you an image, a) without traits, and b) with the old class format.

The aim being to 1) enable folks with code that relies on the old format 
to move up to 3.10 should they so desire 2) Satisfy those who dont like 
the existing traits based traits implementation and would like to have 
something simpler and 3) Provide a starting point for a future simpler 
traits implementation if anyone wants to write it.
> If you had such an image could you use it as a basis for development?
>   
If you take 3.10 and remove traits, its roughly the same as a 3.8 image 
with more toys and bug fixes of 3.9 and 3.10.

A future development for MC1.6+ will be to enable MC packages which 
include traits to automatically load flattened into a non-trait image. 
i.e. traits fans can use them as a design/code reuse tool publishing 
their work as a package that anyone can use.
> How would you update it?
>   
In comparison to which current practice?
> How could you revert an update to it?
>
>   
In comparison to which current practice?

Reverting is part of the DS concept.

Sake/Packages has a Package-level unload function which could work well 
if appropriately configured.
> Basically what I am asking is could this be squeak 4.0 and a basis for future development? 
>   
If someone does the complementary "TraitsLoad", then 
3.11-minimal-load-what-you-need-image can be published without traits. 
However doing this would prevent traits being used unflattened in the 
kernel, so it may be better to leave traits in, with a "flatten all 
traits and remove traits" script or sake-task.
> Or would the image produced just be a curiosity that could not be developed further.
>
> This is different from the question of should it be. That also is important to answer. But the "should"
> question is a political one. I'm just looking for the technical answer to the "could" questions.
>   
Where there is a will there is a way...  subject to further tools support.

regards

Keith