[Pharo-project] 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
2009/7/28 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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 :)
2009/7/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
participants (2)
-
Igor Stasenko -
Stéphane Ducasse