Alan, I appreciate your time and respect your opinion. However, I do indeed consider ANSI's handling of #next to be wrong.
Since I appear to be the outlier here, I will proceed with my backup plan unless I hear otherwise. You are of course correct that I *can* test for the end of stream every time I use #next, but I argue that the entire point of exceptions is to enable things like #next to be used safely, meaning without trusting the programmer to do such things. Note that the exceptions have to have teeth (no default action) in order to provide protection. If you have not read it, I highly recommend Maguier's Writing Solid Code. Be warned about the sub-title: "Microsoft's Techniques for Writing Bug-free C Programs." I know -- too bad they haven't read it! The publisher's hypocrisy aside, it is an excellent book. The chapter "Candy Machine Interfaces" is particularly relevant. Also, do not miss the disassembler example - great stuff! Then think back to your childhood. I just barely remember matchbooks that had the strike strip on the front; the books were of course REALLY old at the time :) Match books still say "close cover before striking," but some clever person decided to put the strip on the back, forcing the user to put some type of barrier between the strip and the remaining match heads. Another Microsoft document offers insight. At least the original MFC tutorials made a point of using new objects w/o testing for error conditions or null pointers, all thanks to exceptions. When I last looked, they pitched "smooth scrolling" (ways to make the computer draw even more than necessary) instead of tackling the finer points of redraw optimization as they once did. Who knows what else was cut. Kinda pathetic, but I digress. Absent robust and consistent use of exceptions, #next is an accident waiting to happen. The simplest course of action for me is to design something that is safe and consistent, and ensure that I use it over inconsistent alternatives. BTW, I do a LOT of stream I/O, so I do not trust myself any more than I do some idiot striking a match :) Happy Smalltalking! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [EMAIL PROTECTED] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> Alan Knight <[EMAIL PROTECTED]> 06/05/08 9:12 PM >>> 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: [EMAIL PROTECTED] >Tel: (352) 846-1285 >FAX: (352) 392-7029 > > >>>> [EMAIL PROTECTED] 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 >[email protected] >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Alan Knight [|], Engineering Manager, Cincom Smalltalk [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cincom.com/smalltalk _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
