On Sun, Jan 3, 2010 at 7:49 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Mariano Martinez Peck wrote:
>
>> As a "repeater offender" you will probably don't answer be. But anyway...
>> we were discussing a couple of days ago with the Pharo guys about unloading
>> and the biggest problem we found were the overrides of the packages. Do you
>> handle this situation?
>>
>
> Sure: Don't use overrides. Overrides are a necessary evil when you can't
> change the underlying system to use proper means of composing the desired
> behavior. However, if you are in control it's plain insanity to use
> overrides. Why in the lord's name would you use overrides unless you
> absolutely, positively had to?
>

Because one is experimenting.  I agree with you Andreas that overrides are
evil and that in a well-designed system they can be eliminated by
well-designed extensibility conventions.  However, in experimentation phases
before such extensibility schemes have been engineered or been justified
economically, good support for overrides are a reasonable substitute, and as
you admit, necessary.  The problem with Monticello's overrides is simply
with their implementation above method versions.  As we've discussed
recently an alternative implementation of a dictionary from overridden item
(method reference or class definition reference) to a dictionary from
package name to version in that package, along with a global package load
order, would allow the system to compute all the overridden items reliably
at any time, and compute the most recent previous version when unloading a
package that overrides.  The modifications to Monticello would be minimal -
maintain a global load order, enter overridden definitions into the override
map on load, and remove entries from the override map on unload.

I know, code speaks louder than words.  I'll see what I can do in my copious
spare time ;)


Cheers,
>  - Andreas
>
>  On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <andreas.raab at gmx.de<mailto:
>> andreas.raab at gmx.de>> wrote:
>>
>>    Folks -
>>
>>    I've been going through various packages, and we're actually capable
>>    of unloading quite a bit of them cleanly by now. I've attached my
>>    unload script which (on a most recent updated trunk image with no
>>    additional packages loaded) will be able to unload the following
>>    packages:
>>    - ReleaseBuilder, ScriptLoader
>>    - 311Deprecated, 39Deprecated
>>    - Universes, SMLoader, SMBase, Installer-Core
>>    - VersionNumberTests, VersionNumber
>>    - Services-Base, PreferenceBrowser, Nebraska
>>    - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
>>    - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
>>    - XML-Parser, Traits
>>    After these packages been unloaded there are no Undeclared
>>    references or obsolete behaviors or modified MC packages. There are
>>    several more candidate packages, some of which I could use some help
>>    with:
>>
>>    * Tests: The tests package is currently not unloadable because it
>>    includes ClassTestCase which is used from several other places.
>>    There is a fundamental question here whether we should aim for
>>    making all tests as well as SUnit unloadable or not. If the former,
>>    then we need to move tests out of packages like Files, System or MC
>>    in order to make them unloadable. If we're not shooting for making
>>    SUnit unloadable it may be worthwhile to promote ClassTestCase up to
>>    SUnit so that the Tests package becomes unloadable. Comments?
>>
>>    * Morphic-Extras: I don't understand the intent of this package. The
>>    name implies to me that it includes "extras" which I'd expect to be
>>    optional content that should be unloadable at will but the reality
>>    is that even attempting to unload it (I foolishly tried) blows up
>>    left and right. Question: Is the intention of Morphic-Extras to
>>    contain unloadable content? If so, it's not doing its job currently.
>>    If that's not the intention of Morphic-Extras, I'd appreciate a
>>    heads-up of what the rationale for the structure is.
>>
>>    * ST80: This is still a bit off but we're getting there. It can
>>    actually be unloaded but there are still several Undeclared
>>    variables and obsolete behaviors after unloading MVC. But the good
>>    news is that the system is still functioning (!) instead of horribly
>>    dying as it used to be. We could use a bit of additional help from
>>    people with an interest in this area.
>>
>>    Cheers,
>>     - Andreas
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100103/569cbcde/attachment.htm