On 25 May 2013 12:40, Igor Stasenko <[email protected]> wrote: > On 25 May 2013 12:55, Camillo Bruni <[email protected]> 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. >
