Fwd: [Bug and Fix] actualclass in presence of classtrait

> since I do not have internet I did not added the bugtracker but
> when we define a method in the class side of a trait we get an error:
>
> because a methodReference can be used on a method attached to a class
> so actualClass does not take into account traits
>
> MethodReference>>actualClass
>
> | actualClass |
> actualClass := Smalltalk at: classSymbol ifAbsent: [^nil].
> classIsMeta ifTrue: [^actualClass classSide].
> ^actualClass
>
> this breaks for example OBMethodCategoryFilter
>
> OBMethodCategoryFilter>>displayString: aStringOrText forParent:  
> pNode child: cNode
> | category |
> ((cNode reference actualClass includesSelector: cNode reference  
> methodSymbol)
>    and: [cNode reference compiledMethod literals includes:  
> #deprecated:])
>       ifTrue: [^aStringOrText asText addAttribute: TextEmphasis  
> struckOut].
>
> category := cNode category.
> (category beginsWith: '*') ifTrue: [
>    ^(category includesSubString: '-overrides')
>        ifTrue: [aStringOrText asText addAttribute: TextEmphasis  
> italic; addAttribute: TextColor red]
>        ifFalse: [aStringOrText asText addAttribute: TextEmphasis  
> italic]].
>
> ^aStringOrText
>
>
> Here is a possible solution
>
> actualClass
>
> | actualClass traitName|
> ('*classTrait' match: classSymbol)
> ifTrue: [ traitName := classSymbol copyUpTo: Character space.
> ^ Smalltalk at: traitName asSymbol ifAbsent: [nil]].
> actualClass := Smalltalk at: classSymbol ifAbsent: [^nil].
> classIsMeta ifTrue: [^actualClass classSide].
> ^actualClass
>
> This raises the question of MethodReference using symbol instead of  
> pointers to objects.
> Funnily the creation methods require a class and not a classname.
> I can understand that in certain occasion (manipulating methods of  
> classes that are not installed in the image
> is cool) but in that case may be we should have
> MethodReference
> RemoteMethodReference
>
> Stef
>
>
>
>

>> since I do not have internet I did not added the bugtracker but
>> when we define a method in the class side of a trait we get an error:
>>
>> because a methodReference can be used on a method attached to a class
>> so actualClass does not take into account traits
>>
>> MethodReference>>actualClass
>>
>>       | actualClass |
>>       actualClass := Smalltalk at: classSymbol ifAbsent: [^nil].
>>       classIsMeta ifTrue: [^actualClass classSide].
>>       ^actualClass
>>
>> this breaks for example OBMethodCategoryFilter
>>
>> OBMethodCategoryFilter>>displayString: aStringOrText forParent:
>> pNode child: cNode
>> | category |
>> ((cNode reference actualClass includesSelector: cNode reference
>> methodSymbol)
>>    and: [cNode reference compiledMethod literals includes:
>> #deprecated:])
>>       ifTrue: [^aStringOrText asText addAttribute: TextEmphasis
>> struckOut].
>>
>> category := cNode category.
>> (category beginsWith: '*') ifTrue: [
>>           ^(category includesSubString: '-overrides')
>>               ifTrue: [aStringOrText asText addAttribute: TextEmphasis
>> italic; addAttribute: TextColor red]
>>               ifFalse: [aStringOrText asText addAttribute: TextEmphasis
>> italic]].
>>
>> ^aStringOrText
>>
>>
>> Here is a possible solution
>>
>> actualClass
>>
>>       | actualClass traitName|
>>       ('*classTrait' match: classSymbol)
>>               ifTrue: [ traitName := classSymbol copyUpTo: Character space.
>>                               ^ Smalltalk at: traitName asSymbol ifAbsent: [nil]].
>>       actualClass := Smalltalk at: classSymbol ifAbsent: [^nil].
>>       classIsMeta ifTrue: [^actualClass classSide].
>>       ^actualClass
>>
>> This raises the question of MethodReference using symbol instead of
>> pointers to objects.
>> Funnily the creation methods require a class and not a classname.
>> I can understand that in certain occasion (manipulating methods of
>> classes that are not installed in the image
>> is cool) but in that case may be we should have
>>       MethodReference
>>       RemoteMethodReference

>>
>> Stef
>>
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>>>>
>> then you don't need the MethodReference,
>> because you having a CompiledMethod(s), which are installed on system.
>> and RemoteMethodReference , which is not.
>>
>> Btw, i am curious myself, what is the point in referencing the methods
>> indirectly (through MethodReference)?
>
> no idea. now this is there and may be we will remove it but for now
> it should work. We should not do everything at the same time.
>
>> Why not just reference directly to CompiledMethod?
>> What it gives in addition to what CompiledMethod itself could answer
>> to you?
>
> Now package :)
>