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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> But I wanted to know what was your experiment to that regards.
>
> Stef
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>  

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

> 2009/2/14 Keith Hodges <[hidden email]>:
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>
>>
>> _______________________________________________
>> 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