On Sat, May 25, 2013 at 12:55 PM, 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? > Hi Cami, firstly I have to say that most of all patches I do to make Pharo Kernel jobs working are really ugly hacks of poor quality :-) Of course I'm firstly trying to make it work somehow. I do not like solutions like asClassIfPresent: too and I do not use them if I have better simple option. And if I use them, I know that I only move the problem because in most cases it crates new unimplemented calls. But that ugly hacks are only one part of the problem and maybe the minor one. The major one is that we integrate code that requires such ugly hacks :-) Nativeboost, UserManager and others are not old additions and they decrease modularity of the system. So when I find time to work on Pharo Kernel, in most cases I do not clean old problems but I need to solve the new ones. It is not the fault of authors of this additions but of our integration system. Classical eggs and chickens problem, we cannot base our integration process on Pharo Kernel processes because it is not ready and it is not ready because we do not have the integration system based on in. So I'm very glad that Esteban started to work hard on it and if we will do sometimes an ugly hack like this, we know that we do not really solve the problem but we move it to the later time. However it is more important for us to solve it soon. With more hands and attention we will be able to do it in a nicer way ;-) Cheers, -- Pavel
