KCP feedback (ii)
ducasse at iam.unibe.ch
Mon May 5 10:53:16 UTC 2003
Ok I agree. the KCP team should have a coherent line on that.
We will see what we will do. I hope to have a meeting today.
On Monday, May 5, 2003, at 01:11 PM, Daniel Vainsencher wrote:
> What I am saying is that class extensions aren't just packagable - they
> are a way to fix (some) dependency problems.
> For example - you could say that compiler is not part of the kernel,
> since we could imagine a small embedded image that receives it's
> compiled methods through the net, from a big image "feeding" it. In
> software engineering terms, Behavior should definitely not depend on
> Compiler, that's ridiculous, we could have different compilers, bla bla
> You can either remove the method Behavior>>compile:, leaving only the
> interfaces on Compiler, or you could move it to a class extension.
> Moving it to a class extension will make sure that compile: will only
> deployed on images that include the compiler (which is correct),
> Behavior will not include broken code, and the user will still be able
> to do self class compile: 'stuff' if he has the right packages loaded.
> The dependency problem is gone. If Behavior>>codeNavigator is a class
> extension from the pacakge CodeBrowser, there's no dependency problem.
> You just need query tools that are class-extension aware, but as I
> some do exist.
> Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
>>> [Why not use class extensions]
>>>> Because right now we do not have a good way of dealing with class
>>>> extensions. As soon as
>>>> we will get a real package notion this will be easy to fix. But may
>>>> we should do that now.
>>>> I did not discuss this point with other.
>>> The DVS method-category-name-convention is a hack, but it works.
>>> Furthermore, PackageInfo itself and SpaghettiTracer provide some
>>> tools that are aware of these class extensions. I think that anyone
>>> refactoring the image now should seriously consider using this kind
>>> class extensions. It might not be pretty, but it's better than making
>>> the code indirect because it can't be put into the correct class.
>> I agree with the use of extensions. This is one of the most powerful
>> open aspect of Smalltalk. We will look at it when we will need them.
>> However in the case of systemNavigation I do not see why I would put
>> them in class
>> extension on Object. The idea behind the core cleaning is to remove
>> and build layer around the core, so systemNavigation is really a layer
>> on top for UI or global queries as such it is better to add it on the
>> tools that use it than to add a global dependencies even via class
>> extension. The fact that I load or not CodeBrowser should not
>> imply that all the objects depends now from SystemNavigation. I see
>> class extension as a
>> really powerful way to add method in a packageable way but we should
>> pay attention
>> about the consequences of adding dependency.
>> If you check where I was forced to introduced systemNavigation you
>> discover that there is
>> a lot of dirty code there too. For example, SmartStream referring to
>> UI, Utilities (;)). In Dictionary because we use subclassing to
>> represent namespaces ;)
>> So besides them I got a really could reuse for all the tools sharing
>> I hope I was clear.
Prof. Dr. Stephane DUCASSE [ | ]
"if you knew today was your last day on earth, what would you
do different? ... especially if, by doing something different,
today might not be your last day on earth" Calvin&Hobbes
Open Source Smalltalks: http://www.squeak.org,
Free books for Universities at
Online Free Books at
More information about the Squeak-dev