> On 12 October 2011 23:22, Levente Uzonyi <[hidden email]> wrote:
>> On Wed, 12 Oct 2011, Mariano Martinez Peck wrote:
>>
>>> On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <[hidden email]> wrote:
>>>
>>>> On Wed, 12 Oct 2011, Clara Allende wrote:
>>>>
>>>>  Hi guys,
>>>>>
>>>>> I'm wondering, why?
>>>>>
>>>>> ProtoObject>> ~~ anObject
>>>>>  "Answer whether the receiver and the argument are not the same object
>>>>>  (do not have the same object pointer)."
>>>>>
>>>>>  self == anObject
>>>>>      ifTrue: [^ false]
>>>>>      ifFalse: [^ true]
>>>>>
>>>>>
>>> Hi Carla. I can think about two things. The first one, is the one Levente
>>> said, performance.
>>> If you analyze the bycode of this method, you will see that it is
>>> extremely
>>> fast because:
>>>
>>> 1) #== has an special associated bytecode, that is, them VM maps such
>>> bytecode to an specific primitive and it is directly executed. It means
>>> that
>>> the method #== is really never sent.
>>> 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, it
>>> method is never executed and instead the compiler replace a message send
>>> bytecode with jump ones.
>>>
>>> Another possible reason (it may not be the case, but in another places it
>>> is), is to prevent VM interruption for check other processes. In summary,
>>> the VM checks whether it should execute another process of the queue after
>>> a
>>> method execution. As you know, some parts of the scheduling process is
>>> done
>>> at the image side. And from there we lack a way to say to the VM, "please
>>> execute this method without checking others processes". Hence, in a few
>>> yet
>>> very specific places of PRocess, Scheduler, Semaphore, etc, #== is used as
>>> a
>>> mean of executing something WITHOUT being interrupted. I can imagine that
>>> it
>>> may happen the same with #~~. So if you implement such method with a #not,
>>> you will indeed send a message, proving a possibilty to be interrupted.
>>
>> I don't see how this would be a reason. When you send #~~, then you
>> explicitly allow a suspension point, so not using #not won't avoid
>> suspension points.
>>
>
> To my thinking, in a first place, i would ask:
> why instead of fixing the code which may be affected by having or not
> suspension points,
> we introducing new workarounds ??

>
>>>
>>> Another reasons, similar to the previous one, is that sometimes #== is
>>> also
>>> used as a way to avoid executing method. So..there are some methods (I
>>> don't
>>> remember if #allInstancesDo: or #allObjectsDo:) will loop forever because
>>
>> #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: uses a
>> custom marker object, so creating new objects won't cause infinite loop
>> (because gc doesn't change the order of any two objects).
>>
>>> the loop condition would be creating objects (remember that method
>>> execution
>>> creates objects such as MethodContext).
>>
>> Contexts object are not created until requested and these loops don't need
>> contexts. Some old methods interating through all/some objects use 0 as the
>> marker object. These may have problems with objects created during their
>> loops.
>>
>>
>> Levente
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>