[Pharo-project] Fwd: A question about hardcoded class names
Hi guys some days ago with alex we wanted to identify the methods containing a reference to their class (Lint does it too). Now we thought that replacing them with self class is not equivalent since we could imagine that hardcoding the class name make sure that subclass cannot redefine methods. Now this is a bit against Smalltalk late bindinness and probably most of the time an newbie error. But I wanted to know what was your experiment to that regards. Stef
Now we thought that replacing them with self class is not equivalent since we could imagine that hardcoding the class name make sure that subclass cannot redefine methods.
No, in many cases this is not equivalent. In my opinion the rule could avoid many false positives if it would only trigger if there are no subclasses. Of course we would then also get more false negatives.
But I wanted to know what was your experiment to that regards.
Two typical false positives I encountered: 1. Factory or builder methods on the class side usually refer to a wide variety of classes. Sometimes such methods also refer to the receiving class, however since you want to make the method also work when called on subclasses you have to hardcode the receiving class. 2. When collecting pragmas you usually write something along: PRErrorView>>renderOptionsOn: html (Pragma allNamed: #option: from: self class to: PRErrorView) do: [ :each | ... ] Given that PRErrorView has the subclasses PRForbiddenView and PRNotFoundView, there are cases where "self class" is not equal to PRErrorView. And the point of the above code is to find all pragmas, up to PRErrorView. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Another example... the KeyedTree methods I commented on. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, February 14, 2009 4:19 PM Subject: Re: [Pharo-project] Fwd: A question about hardcoded class names
Now we thought that replacing them with self class is not equivalent since we could imagine that hardcoding the class name make sure that subclass cannot redefine methods.
No, in many cases this is not equivalent. In my opinion the rule could avoid many false positives if it would only trigger if there are no subclasses. Of course we would then also get more false negatives.
But I wanted to know what was your experiment to that regards.
Two typical false positives I encountered:
1. Factory or builder methods on the class side usually refer to a wide variety of classes. Sometimes such methods also refer to the receiving class, however since you want to make the method also work when called on subclasses you have to hardcode the receiving class.
2. When collecting pragmas you usually write something along:
PRErrorView>>renderOptionsOn: html (Pragma allNamed: #option: from: self class to: PRErrorView) do: [ :each | ... ]
Given that PRErrorView has the subclasses PRForbiddenView and PRNotFoundView, there are cases where "self class" is not equal to PRErrorView. And the point of the above code is to find all pragmas, up to PRErrorView.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes this is what I thought so we will have to go over them one by one and tag them Stef On Feb 14, 2009, at 5:19 PM, Lukas Renggli wrote:
Now we thought that replacing them with self class is not equivalent since we could imagine that hardcoding the class name make sure that subclass cannot redefine methods.
No, in many cases this is not equivalent. In my opinion the rule could avoid many false positives if it would only trigger if there are no subclasses. Of course we would then also get more false negatives.
But I wanted to know what was your experiment to that regards.
Two typical false positives I encountered:
1. Factory or builder methods on the class side usually refer to a wide variety of classes. Sometimes such methods also refer to the receiving class, however since you want to make the method also work when called on subclasses you have to hardcode the receiving class.
2. When collecting pragmas you usually write something along:
PRErrorView>>renderOptionsOn: html (Pragma allNamed: #option: from: self class to: PRErrorView) do: [ :each | ... ]
Given that PRErrorView has the subclasses PRForbiddenView and PRNotFoundView, there are cases where "self class" is not equal to PRErrorView. And the point of the above code is to find all pragmas, up to PRErrorView.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Hi guys
some days ago with alex we wanted to identify the methods containing a reference to their class (Lint does it too). Now we thought that replacing them with self class is not equivalent since we could imagine
st/x uses here class
that hardcoding the class name make sure that subclass cannot redefine methods. Now this is a bit against Smalltalk late bindinness and probably most of the time an newbie error.
I doubt it. isAbstract self class = here class. Keith
But I wanted to know what was your experiment to that regards.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/14 Keith Hodges <keith_hodges@yahoo.co.uk>:
Stéphane Ducasse wrote:
Hi guys
some days ago with alex we wanted to identify the methods containing a reference to their class (Lint does it too). Now we thought that replacing them with self class is not equivalent since we could imagine
st/x uses
here class
that hardcoding the class name make sure that subclass cannot redefine methods. Now this is a bit against Smalltalk late bindinness and probably most of the time an newbie error.
I doubt it.
isAbstract
self class = here class.
If i understood, st/x here class is equivalent to squeak thisContext method methodClass right?
Keith
But I wanted to know what was your experiment to that regards.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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.
The class CUCastingExample in the following Pharo image <http://scg.unibe.ch/Research/DSL/diesel-languageaspects.zip> contains some language experiments along these lines. For example the keyword "this" starts the lookup of in the class the method is defined in. Similar receivers of message sends can be casted to any superclass using #cast:. Lukas On Sat, Feb 14, 2009 at 6:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2009/2/14 Keith Hodges <keith_hodges@yahoo.co.uk>:
Stéphane Ducasse wrote:
Hi guys
some days ago with alex we wanted to identify the methods containing a reference to their class (Lint does it too). Now we thought that replacing them with self class is not equivalent since we could imagine
st/x uses
here class
that hardcoding the class name make sure that subclass cannot redefine methods. Now this is a bit against Smalltalk late bindinness and probably most of the time an newbie error.
I doubt it.
isAbstract
self class = here class.
If i understood, st/x
here class
is equivalent to squeak
thisContext method methodClass
right?
Keith
But I wanted to know what was your experiment to that regards.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
participants (5)
-
Gary Chambers -
Igor Stasenko -
Keith Hodges -
Lukas Renggli -
Stéphane Ducasse