Re: [Pharo-project] About on:
Stef, Damien, No surprise, I would argue that we proceed, and would also include a rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in the image at the time should work as before. The next step (part B) would be to add exception-aware #next and #next:. Damien and I could cook it up, try it, and then return with an "all clear." Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
stephane.ducasse@inria.fr 6/4/2008 10:36 AM >>>
On Jun 4, 2008, at 5:20 PM, Damien Cassou wrote:
On Wed, Jun 4, 2008 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
here is what I propose for on: I will move your package out of the inbox so that the discussion can go on and I try to integrate all the other changes. Then with bill and others you propose how to proceed. Is it ok ?
What do you mean by 'I will move your package out of the inbox'? Do you mean you simply delete the packages or you moved them to Pharo?
I mean move them to the treatedBox without putting in the image
Replacing 'ReadStream on: smth' by 'smth readStream' is not mandatory. However, it makes the code simpler to read, avoids a direct class reference and allows different implementation of #readStream depending on the kind of collection it is sent to. I do not think anyone is against that as soon as I apply the automatic refactoring carefully. I did that and didn't see any place where the RB did a bad job. It even detected that SequenceableCollection>>readStream should not be changed to avoid infinite recursion.
Do you think there is a problem that I might take care of?
Now as a group how do we want to handle this case? We give a try and trust damien? Stef
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
_______________________________________________ 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
On Jun 5, 2008, at 00:27 , Bill Schwab wrote:
Stef, Damien,
No surprise, I would argue that we proceed, and would also include a rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in the image at the time should work as before.
What would be the impact on code that is not in the image? Would all external packages need to be adapted as well or would the current semantics be preserved? Adrian
The next step (part B) would be to add exception-aware #next and #next:.
Damien and I could cook it up, try it, and then return with an "all clear."
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
stephane.ducasse@inria.fr 6/4/2008 10:36 AM >>>
On Jun 4, 2008, at 5:20 PM, Damien Cassou wrote:
On Wed, Jun 4, 2008 at 1:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
here is what I propose for on: I will move your package out of the inbox so that the discussion can go on and I try to integrate all the other changes. Then with bill and others you propose how to proceed. Is it ok ?
What do you mean by 'I will move your package out of the inbox'? Do you mean you simply delete the packages or you moved them to Pharo?
I mean move them to the treatedBox without putting in the image
Replacing 'ReadStream on: smth' by 'smth readStream' is not mandatory. However, it makes the code simpler to read, avoids a direct class reference and allows different implementation of #readStream depending on the kind of collection it is sent to. I do not think anyone is against that as soon as I apply the automatic refactoring carefully. I did that and didn't see any place where the RB did a bad job. It even detected that SequenceableCollection>>readStream should not be changed to avoid infinite recursion.
Do you think there is a problem that I might take care of?
Now as a group how do we want to handle this case? We give a try and trust damien?
Stef
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Jun 5, 2008 at 8:52 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Jun 5, 2008, at 00:27 , Bill Schwab wrote:
Stef, Damien,
No surprise, I would argue that we proceed, and would also include a rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in the image at the time should work as before.
What would be the impact on code that is not in the image? Would all external packages need to be adapted as well or would the current semantics be preserved?
In the case of changing 'ReadStream on: smth' to 'smth readStream' there is really nothing to change in external libraries. This change only enhance the code without changing anything. The refactoring can also be applied in some parts of the image without changing others. The change Bill proposes is completely different and I would propose to postpone it until we have more discussions and everybody agrees. There is no point in doing both at the same time. The changes are completely independent. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
No surprise, I would argue that we proceed, and would also include a rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in the image at the time should work as before.
What would be the impact on code that is not in the image? Would all external packages need to be adapted as well or would the current semantics be preserved?
I suggest to implement #next so that it throws an EndOfStream notification. The default action would return nil, so no existing code needs to be changed. People that want to use exceptions capture the notification. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Thu, Jun 5, 2008 at 12:01 PM, Lukas Renggli <renggli@gmail.com> wrote:
No surprise, I would argue that we proceed, and would also include a rename of #next to #nextOrNil and #next: to #nextAvailable:. All code in the image at the time should work as before.
What would be the impact on code that is not in the image? Would all external packages need to be adapted as well or would the current semantics be preserved?
I suggest to implement #next so that it throws an EndOfStream notification. The default action would return nil, so no existing code needs to be changed. People that want to use exceptions capture the notification.
That's what is in VW apparently. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
participants (4)
-
Adrian Lienhard -
Bill Schwab -
Damien Cassou -
Lukas Renggli