On 5/25/13 8:02 AM, "Esteban Lorenzano" <[email protected]> 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 <[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?
>
>
Could say the url for dowloading the last PharoKernel ?
Edgar
