On Apr 13, 2011, at 5:31 AM, Pat Maddox wrote:
> On Apr 12, 2011, at 3:24 PM, Simon Denier wrote:
>
>>
>> On 12 avr. 2011, at 23:47, Werner Kassens wrote:
>>
>>> hi,
>>> i have a testsuite that is a subclass of TestCase with this method:
>>>
>>> testStupid
>>> |a|
>>> a :=#(1).
>>> self assert: a first isNumber .
>>> a :=a at:1 put: nil.
>>>
>>> if i run the test once, it succeeds, but but when i run it a second time it
>>> fails. this seems to be sligthly counterintuitive, or how do i have to
>>> understand it?
>>
>>
>> Interesting, I would never have guessed the test would be broken at first
>> sight. So maybe some people enlightened in the ways of the compiler can
>> provide a better explanation than me. Here is my guess:
>>
>> #(1) is a special construct which creates a compile-time array. The
>> compile-time makes the trick: in short the array is more or less encoded
>> directly into the bytecodes of the method as a constant.
>> But modifying the array with #at:put: directly modifies the bytecodes in the
>> compiled method itself. So you create a side-effect directly into your
>> method.
>>
>> Am I the only one to find this a bit dangerous and not intuitive? Is it a
>> well-known behavior?
>
> I would never have guessed that in a million years.
>
I like this method:
mystery
'mystery' isString ifTrue: ['mystery' become: {0}].
'mystery' at: 1 put: 'mystery' first + 1.
^ 'mystery' first.
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
