On Sat, Aug 18, 2012 at 1:02 PM, Frank Shearar <frank.shearar@gmail.com> wrote:

On 18 August 2012 11:57, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
>
>
> On Sat, Aug 18, 2012 at 12:33 PM, Camillo Bruni <camillobruni@gmail.com>
> wrote:
>>
>>
>> On 2012-08-17, at 22:50, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>>
>> > On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck <
>> > marianopeck@gmail.com> wrote:
>> >
>> >> Hi guys. Right now we have
>> >>
>> >> methodClass
>> >> "answer the class that I am installed in"
>> >> ^self numLiterals > 0
>> >> ifTrue: [ (self literalAt: self numLiterals) value ]
>> >> ifFalse: [ nil ]
>> >>
>> >> But of course my image has no method with 0 literals:
>> >>
>> >> (CompiledMethod allInstances select: [:each | each numLiterals = 0 ])
>> >> size
>> >> -> 0
>> >>
>> >> So...can this really happen? or I can just remove the if ?
>> >>
>> >
>> > Yes it could happen. �For example, i the Newspeak implementation above
>> > Squeak these is a collection of inst-var accessors that are shared
>> > through
>> > all Newspeak classes in the system.
>>
>> so it will never happen in Pharo right?
>>
>> > These have a nil methodClass. �If one
>> > wanted to save space they could have no methodClass instead of nil in
>> > the
>> > methodClass slot. �(Note that the above works for these since nil value
>> > =
>> > value). �So IMO its a harmless piece of defensice programming. �IIABDFI
>> > (If
>> > it ain't broke don't fix it).
>>
>> again, this is not pharo mentality...
>>
>
> Yes, that was my point. Our system is full of �"xx > yyy ifZZ:" ,
> "isEmptyOrNil ifZZ:", "ifNil: " blah blah blah. I am sure lost of them were
> workaround introduced to solve a problem in some point in time in the last
> 20 years. And not only at a point in time, but also together with an
> specific image version, set of libraries, vm, etc. I am also sure lots of
> them may not be necessary anymore after so many cleanings and library
> replacement. Hence, my question.
>
> Finally, if Pharo would have followed the IIABDFI (If it ain't broke don't
> fix it) then we would still have ReferenceStream, ImageSegment, HTTPSocket,
> Preferences, FileDirectory, SystemChangeNotifier, �and many others around
> (of course, someone could consider them as broken).

Replacing something is not the same as removing things you think will
never happen. Oftentimes, yes, those crazy bits of nonsense were added
a decade ago _for very good reason_, even if the committe failed his
good citizenry test by documenting it. You can get yourself into very
nasty trouble by randomly fixing things that aren't broken. Especially
if you're not quite sure what the crazy nonsense is for.

Replacing something is not the same as removing, I agree. But if the hacks or workaround were for a particular very good reason and some point in time, with certain image and libraries, why to keep it NOW in Pharo? �Say ReferenceStream had some hacks around the system. Now we have removed it. Why should we keep the hacks in Pharo itself? No problem if someone wants to install ReferenceStream again in Pharo. But if you do so, bring with you all the hacks/workarounds to make it work. We will not keep the garbage in the main image.�

Take this very example of #methodClass. Why would be need to keep the "self literals > 0" ? (if the reasons are what Eliot said). If then Newspeak wants to be built on top of Pharo, great, bring the changes (like this one) with you.�

Finally, I am not afraid/shame of rollbacking. I prefer to clean something and then discover that it was actually needed �than do nothing. In fact, I would be able to document why it was needed ;)

�

frank

> --
> Mariano
> http://marianopeck.wordpress.com
>