On 5/25/13 8:02 AM, "Esteban Lorenzano" <estebanlm@gmail.com> wrote:
well... I said the same when I was applying those changes, he :) I already made a note in my TODO list to refactor that as soon as possible too :)
Esteban
On May 25, 2013, at 12:55 PM, 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?
Could say the url for dowloading the last PharoKernel ? Edgar