On 25 May 2013 11: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?
Like Stef says, using #asClassIfPresent makes things worse because the dependency is still there, only harder to find. Returning nil adds another problem, in that you can end up with an UndefinedObject >> #doesNotUnderstand: far away from the cause of the problem. The first way I've worked with these is moving UnixResolver >> #nbGetNev: to the NativeBoost package. That means that NativeBoost -> UnixResolver, which at least is a dependency pointing in the right direction. (I'm ignoring the fact that in this case there's clearly a platform difference issue: UnixResolver makes no sense on a Windows machine, obviously.) Another approach is to have something like an AppRegistry subclass. This is a class that has a #register: method which lets you set the class of something. Maybe it's a mail client, maybe it's the main browser class. That provides in the lower packages a hook. Other packages can just refer to the hook, and the higher level packages can use that hook to get called, without lower level packages depending on those higher level packages. frank
