Hi,
I'm interested in enhancing the code of Pharo (and maybe Squeak if the community is interested). Currently, I'm thinking about replacing 'ReadStream on: expr' by 'expr readStream'.
I can see the following advantages of this change:
- no more direct reference on ReadStream where it is not necessary - allows different implementation of #readStream depending on the receiver class - clarify the code
Can you detect any problem with this approach?
The RefactoringBrowser allows this change to be done simply in all the method of the image.
Damien Cassou wrote:
Can you detect any problem with this approach?
That transformation should be safe. I can think of some situations that would cause problems (for example an external client which implements #readStream incorrectly) but broken code is broken code so I wouldn't worry too much about it.
Cheers, - Andreas
2008/6/4 Damien Cassou damien.cassou@gmail.com:
Hi,
I'm interested in enhancing the code of Pharo (and maybe Squeak if the community is interested). Currently, I'm thinking about replacing 'ReadStream on: expr' by 'expr readStream'.
I can see the following advantages of this change:
- no more direct reference on ReadStream where it is not necessary
- allows different implementation of #readStream depending on the receiver class
- clarify the code
Can you detect any problem with this approach?
The RefactoringBrowser allows this change to be done simply in all the method of the image.
Yeah, but it also pretty prints the code.
Cheers Philippe
On Wed, Jun 4, 2008 at 6:30 PM, Philippe Marschall philippe.marschall@gmail.com wrote:
2008/6/4 Damien Cassou damien.cassou@gmail.com:
Hi,
I'm interested in enhancing the code of Pharo (and maybe Squeak if the community is interested). Currently, I'm thinking about replacing 'ReadStream on: expr' by 'expr readStream'.
I can see the following advantages of this change:
- no more direct reference on ReadStream where it is not necessary
- allows different implementation of #readStream depending on the receiver class
- clarify the code
Can you detect any problem with this approach?
The RefactoringBrowser allows this change to be done simply in all the method of the image.
Yeah, but it also pretty prints the code.
Another advantage (thank you Philippe):
- the source code is prettier :-D
(the only problem is with the strange meaning RB assigns to 'pretty' :-)
Damien Cassou wrote:
The RefactoringBrowser allows this change to be done simply in all the method of the image.
Yeah, but it also pretty prints the code.
Eeeek!
Another advantage (thank you Philippe):
- the source code is prettier :-D
(the only problem is with the strange meaning RB assigns to 'pretty' :-)
Indeed. Don't do that. Reformatting code that ain't yours should be done with great care if at all. Letting some so-called "pretty" printer do it on a handful of methods at random is just evil.
Cheers, - Andreas
On Wed, 4 Jun 2008 17:54:51 +0200, "Damien Cassou" damien.cassou@gmail.com wrote:
Currently, I'm thinking about replacing 'ReadStream on: expr' by 'expr readStream'.
As far as I can tell, this method has been around in SequenceableCollection since sometime in 2000, at least in "normal" Squeak...
I've got a virgin Squeak 3.1 image that has it...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
On Wed, Jun 4, 2008 at 6:47 PM, Jon Hylands jon@huv.com wrote:
On Wed, 4 Jun 2008 17:54:51 +0200, "Damien Cassou" damien.cassou@gmail.com wrote:
Currently, I'm thinking about replacing 'ReadStream on: expr' by 'expr readStream'.
As far as I can tell, this method has been around in SequenceableCollection since sometime in 2000, at least in "normal" Squeak...
I've got a virgin Squeak 3.1 image that has it...
What do you imply?
I don't want to remove ReadStream>>on:, only use another level of indirection by using the already existing method #readStream. I think this method has been made to avoid the use of ReadStream>>on: that's why I believe this change is interesting.
On Wed, 4 Jun 2008 18:52:37 +0200, "Damien Cassou" damien.cassou@gmail.com wrote:
What do you imply?
I don't want to remove ReadStream>>on:, only use another level of indirection by using the already existing method #readStream. I think this method has been made to avoid the use of ReadStream>>on: that's why I believe this change is interesting.
Oh, I'm sorry - I was thinking you wanted to implement #readStream, but you're saying you want to fix all senders of #on: to use #readStream...
Sorry, my misunderstanding...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
Damien Cassou wrote:
Hi,
I'm interested in enhancing the code of Pharo (and maybe Squeak if the community is interested). Currently, I'm thinking about replacing 'ReadStream on: expr' by 'expr readStream'.
And #writeStream of course.
I can see the following advantages of this change:
- no more direct reference on ReadStream where it is not necessary
- allows different implementation of #readStream depending on the receiver class
- clarify the code
+1. In GNU Smalltalk I have added WriteStream>>#readStream and this not only adds polymorphism, it makes code faster by removing the copy made by #contents.
Can you detect any problem with this approach?
The RefactoringBrowser allows this change to be done simply in all the method of the image.
If you're willing to review the changes by hand, you can more or less easily modify the Refactoring Browser's ParseTreeRewriter so that it prettyprints only the replacement text, not everything. This solution would be pretty ad hoc; and as I said, I think it would require manual review. But in my opinion it is worth the effort for this kind of refactoring.
Paolo
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Damien Cassou -
Jon Hylands -
Paolo Bonzini -
Philippe Marschall