i'd vote for keeping #== .

Remember there was a discussion whether:

'abc' == 'abc'

should answer true or false.

And if it returns false, meaning that compiler doesn't bother to
optimize literals used, then
#hasLiretal:
should also use #== .

Also, suppose that

aMethod hasLiteral: #DateAndTime->DateAndTime

answers true.
But method's literal holds a variable binding , but not association
which you just created.
And then if you try something like following:

assoc := #DateAndTime -> DateAndTime.
(aMethod hasLiteral: assoc) ifTrue: [ assoc value: Foo ].

it won't make any effect on method, since it using different object.
So, many tools (especially refactoring ones) can be confused by this,
if they using #hasLiteral: in combination with mutating/replacing
those literals .


On 19 July 2011 19:52, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Tue, Jul 19, 2011 at 10:44 AM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> Hmm, there's the tricky edge case:
>>
>> 0.5s2 = 0.5s3
>> 0.5s2 class = 0.5s3 class.
>>
>> But they should be different literals.
>> I think there is a test case for it.
>>
>> Same goes for arrays
>>
>> #( 0 ) = #( 0.0 )
>>
>> I think we defined a #literalEquals: or something like that to handle this
>> kind of cases.
>
> Yes, indeed.  I can change this.  But before doing so does anyone else agree
> that the whole hasLiteral: hasLiteralThorough: is too heavy-weight and we
> should ditch hasLiteralThorough: and make hasLiteral: be thorough?  And I
> suppose more importantly does anyone disagree?
>
>>
>> Nicolas
>>
>> 2011/7/19 Eliot Miranda <eliot.miranda at gmail.com>
>>>
>>>
>>> On Mon, Jul 18, 2011 at 2:40 PM, Sean P. DeNigris <sean at clipperadams.com>
>>> wrote:
>>>>
>>>> I tried:
>>>>
>>>>    aMethod hasLiteral: #DateAndTime->DateAndTime
>>>>
>>>> and got false, even though an "=" literal is indeed there.
>>>>
>>>> Why doesn't #hasLiteral: use #=?
>>>
>>> Well, the tricky thing with literals is that 0.0 = 0 and 'one' = #one but
>>> these are all different literals.  That said, it looks like a bug to me.  It
>>> should surely be
>>> !CompiledMethod methodsFor: 'literals' stamp: 'eem 7/19/2011 09:19'!
>>> hasLiteral: literal
>>> | litClass lit |
>>> "Answer whether the receiver references the argument, literal."
>>> litClass := literal class.
>>> 2 to: self numLiterals - 1 do: "exclude superclass + selector/properties"
>>> [:index |
>>> lit := self objectAt: index.
>>> (litClass == lit class and: [literal = lit]) ifTrue: [^true]].
>>> ^false! !
>>> !Array methodsFor: 'private' stamp: 'eem 7/19/2011 09:20'!
>>> hasLiteral: literal
>>> "Answer true if literal is identical to any literal in this array, even
>>> if imbedded in further array structure. This method is only intended
>>> for private use by CompiledMethod hasLiteralSymbol:"
>>> | litClass lit |
>>> litClass := literal class.
>>> 1 to: self size do:
>>> [:index |
>>> (litClass == (lit := self at: index) class
>>> and: [literal = lit]) ifTrue: [^true].
>>> (Array == lit class
>>> and: [lit hasLiteral: literal]) ifTrue: [^true]].
>>> ^false! !
>>> I've run all the tests in a trunk 4.2 before and after and making the
>>> above change makes no difference.  So I think I'll go ahead and commit the
>>> change to Squeak trunk.  I'll leave the Pharo folks to apply it there-in.
>>>  Files attached.
>>>>
>>>> Thanks.
>>>> Sean
>>>>
>>>> --
>>>> View this message in context:
>>>> http://forum.world.st/Why-does-CompiledMethod-hasLiteral-use-tp3676573p3676573.html
>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> best,
> Eliot
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.