How to deal with issue 1594

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

How to deal with issue 1594

gcotelli
During the sprint in baires we write some tests to detect the senders of = nil to be replaced with isNil as the issue suggest.

We now need to do a rewrite of this methods (this could be done using the refactoring engine as lukas proposed in the issue). However if I do this rewrite on the Dev image I will change code not only in Pharo Core but also in some external packages. Is it the intended scope of the issue?.

I think that first we need to do the rewrite on Pharo Core code.
And let every package maintainer to decide if he wants to do it or not. Of course for the community maintained packages we can make that decision too.

In the future I think would be good to have some kind of "Pharo Coding Practices" (or the name we want) that can be automatically tested. As a community we can discuss this practices and provide some automatic way to ensure that. 

As soon as posible I will create a Slice with the changes in Pharo Core and post it to the inbox (sorry if it takes me some days but here where are celebrating the argentinean bicentennial so i don't have too much free time this days :) ).

Regards,
Gabriel


_______________________________________________
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: How to deal with issue 1594

Igor Stasenko
2010/5/25 Gabriel Cotelli <[hidden email]>:
> During the sprint in baires we write some tests to detect the senders of =
> nil to be replaced with isNil as the issue suggest.


and what if i intentionally may want to implement:

MyClass>> = anObject
  ^ anObject == nil

to make my object to be 'equal' to nil?

> We now need to do a rewrite of this methods (this could be done using the
> refactoring engine as lukas proposed in the issue). However if I do this
> rewrite on the Dev image I will change code not only in Pharo Core but also
> in some external packages. Is it the intended scope of the issue?.
> I think that first we need to do the rewrite on Pharo Core code.
> And let every package maintainer to decide if he wants to do it or not. Of
> course for the community maintained packages we can make that decision too.
> In the future I think would be good to have some kind of "Pharo Coding
> Practices" (or the name we want) that can be automatically tested. As a
> community we can discuss this practices and provide some automatic way to
> ensure that.
> As soon as posible I will create a Slice with the changes in Pharo Core and
> post it to the inbox (sorry if it takes me some days but here where are
> celebrating the argentinean bicentennial so i don't have too much free time
> this days :) ).
> Regards,
> Gabriel
>
> _______________________________________________
> 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: How to deal with issue 1594

Stéphane Ducasse
In reply to this post by gcotelli
Thanks gabriel and happy celebration!

Stef
On May 25, 2010, at 7:00 AM, Gabriel Cotelli wrote:

> During the sprint in baires we write some tests to detect the senders of = nil to be replaced with isNil as the issue suggest.
>
> We now need to do a rewrite of this methods (this could be done using the refactoring engine as lukas proposed in the issue). However if I do this rewrite on the Dev image I will change code not only in Pharo Core but also in some external packages. Is it the intended scope of the issue?.
>
> I think that first we need to do the rewrite on Pharo Core code.
> And let every package maintainer to decide if he wants to do it or not. Of course for the community maintained packages we can make that decision too.
>
> In the future I think would be good to have some kind of "Pharo Coding Practices" (or the name we want) that can be automatically tested. As a community we can discuss this practices and provide some automatic way to ensure that.
>
> As soon as posible I will create a Slice with the changes in Pharo Core and post it to the inbox (sorry if it takes me some days but here where are celebrating the argentinean bicentennial so i don't have too much free time this days :) ).
>
> Regards,
> Gabriel
>
> _______________________________________________
> 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