Begin forwarded message:
From: Alan Knight <knight@acm.org> Date: June 6, 2008 2:05:34 PM CEDT To: pharo-project-owner@lists.gforge.inria.fr Cc: "Bill Schwab" <BSchwab@anest.ufl.edu> Subject: Re: [Pharo-project] About on:
I guess I'm a non-member and not allowed to post, but it'd probably be good if you could forward this.
Um, I guess that'd be me, but I'm missing a bit of context here. I guess you're probably not talking about #on:, but about #next, which I had discussed earlier with Bill.
I had glanced at the ANSI standard and it appeared to me that it left the behaviour undefined. I don't know if you could characterize that as "wrong". A bad idea, perhaps, but it can't be wrong because it doesn't say anything.
With respect to next, what VisualWorks does is raise an EndOfStream exception which is a notification. If not caught, it proceeds with nil. I don't think this is a good idea, and would like to at least make it not common behaviour. But I can't see changing the behaviour that a read past end of stream results in a nil. That assumption is pretty deep in a lot of Smalltalk code, and I think (without checking) that it is what all the dialects except Dolphin do.
I note that it's not necessary to avoid the use of next in your own code if you don't like the behaviour. Just use it in conjunction with an atEnd test.
At 09:27 AM 6/5/2008, Bill Schwab wrote:
Lukas,
I have blind copied someone who can comment, or not at his discretion, on Cincom's view on this; he never said he was commenting off the record, but I try to err toward assuming that. I got the distinct sense that they are contemplating a change of some type and are also struggling with backward compatibility.
You are correct about ANSI; I was shocked to see what they did. Without reservation, I assert the standard is wrong. Exception handling was created to allow the widespread elimination of precisely the condition that arises when #next reads off the end of a stream. I can always (and probably will if we do not fix this) deprecate #next and #next: in my own work, but that still leaves inconsistencies between and within dialects.
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
renggli@gmail.com 6/5/2008 7:18 AM >>> Yes, but it is not consistent, and they are apparently not happy with it.
Why? Can you give any pointers?
Object Arts' solution is consistent both with itself and with yoga of structured exception handling. However, at this point, it appears that you do not want to make the change, so I will stop pressing.
As far as I see this is inconsistent with the ANSI standard.
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
-- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight@acm.org aknight@cincom.com http://www.cincom.com/smalltalk
-- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight@acm.org aknight@cincom.com http://www.cincom.com/smalltalk