[squeak-dev] Unload Traits script
Keith Hodges
keith_hodges at yahoo.co.uk
Sat May 10 23:36:13 UTC 2008
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
More information about the Squeak-dev
mailing list
|