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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse
> 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
Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
2009/7/28 Stéphane Ducasse <[hidden email]>:

>> 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
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)?
Why not just reference directly to CompiledMethod?
What it gives in addition to what CompiledMethod itself could answer to you?

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse
>>>
> 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 :)

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
2009/7/29 Stéphane Ducasse <[hidden email]>:

>>>>
>> 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 :)
>
you mean by adding the 'package' ivar to it?
Then it makes sense to some sort - to be able to walk back from method
to package,
in addition to walking from package to particular method.
But i wonder, where it could be useful?
Browser browsing real classes and in order to create MethodReference
from CompiledMethod (for whatever reason), it still
needs to determine to which package it belongs to beforehead - in
order to fill that ivar :) .


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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse
When you have a class extension you need to know if a method belong to  
a package or another one.
Now when enumerating methods you can always ask all the package which  
one
defines the methods or simply asks the methodreference (in my rewrite  
of package I extended methodReference
to avoid asking all the packages all the times).

Stef

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