On 25 May 2013 12:40, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 May 2013 12:55, Camillo Bruni <camillobruni@gmail.com> wrote:
I've seen a lot of progress for the Pharo Kernel by Pavel recently and I really appreciate his work. But I have some questions I think we should discuss.
There have been quite a few changes to make code work in the Kernel and to reduce dependencies between packages. But I really have the impression that many of these changes are of bad quality :/.
I do not want to offend people, but this is fairly important if we want to have a nice code base.
Example: ======== UnixResolver >> nbGetEnv: str #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. ^ nil
The goal of this code is to conditionally do something in the main image but continue to work in the kernel.
Observations: ============= - #asClassIfPresent: and Co are bad - Why do we clutter the main image if the kernel should change? - Can't we solve these things by having proper other objects? - Is the UnixResolver really needed in the Kernel?
I worked with Esteban last week on a similar case in the CommandLineHandler and we ended up introducing a minimal superclass. I guess this goes much in the direction of having proper NullObjects.
I really think we should not add these little nasty changes, but rather introduce proper new classes that can be unloaded if needed.
What do you think?
hmm.. what about factoring out this functionality in separate package, say "Kernel-Extras" and keep dependencies there. Another approach is using delegates, e.g. when kernel class provides an API while concrete implementation is provided in separate package. That i think same idea as with superclass, which defines common/required interface, and then self-configuring itself depending on what packages are in system and what services registered by them. Then, of course, you need to provide either fallback code or stub code (null pattern).
So if I'd read the entire thread before posting (who on earth does _that_?), I'd have read this. Yes, this is exactly what my mail meant. The low level packages can refer to _something_, and some higher level package can be plugged into _something_'s hole. frank
-- Best regards, Igor Stasenko.