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). -- Best regards, Igor Stasenko.
