Begin forwarded message:
From: Alan Knight <[EMAIL PROTECTED]>
Date: June 6, 2008 2:05:34 PM CEDT
To: [EMAIL PROTECTED]
Cc: "Bill Schwab" <[EMAIL PROTECTED]>
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: [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
--
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
