On 2013-05-26, at 10:57, "Edgar J. De Cleene" <[email protected]> wrote:
> 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 ?
You'll find it on the pharo-contribution CI:
https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/
