PositionnableStream>>peekFor: not standard

Ron Teitelbaum Ron at USMedRec.com
Wed Feb 28 19:35:17 UTC 2007


All,

Things will definitely break.  I guess the question is should we change
known senders and have the code break in other places.

I know I ran into this and was shocked when peekFor: didn't peek!  I didn't
use it because of that and used peek instead.  I wondered about why this was
done and realized that in most places where we know what we are looking for
we just pop it off anyway, so even though I didn't want to write code like
that I kinda understood.

So I agree it should be changed because even though it matches how we use
it, it is confusing and would be difficult for many to follow.  It also
performs contrary to how new programmers would think it should.

I don't think it should be changed because debugging a problem of this sort
could be very difficult.  It is possible that the code doesn't break at
peakFor: but after when the peakedFor character is encountered later, if at
all.  Also in many cases the peakedFor character is non-readable and would
cause matching problems where matching problems didn't exist before.  It
would be even more difficult to find out what happened because who would
think that peakFor: would change!  The error (having extra non-readable
characters that should have been pop'd off) could easily propagate into data
and be a real bear to clean.

I have no idea how we communicate this to people that are upgrading.  I like
that in seaside we have a deprecated method to highlight code that shouldn't
be used.  It would be nice if we had something similar that allowed users to
see that code they are using has changed not just in implementation but in
function.  Something that in development threw messages to the transcript
but that could be acknowledged so that it goes away.

Anyway I'm not sure what we should do.  It is wrong in my opinion, but it
doesn't affect my code and could do some major damage to others.

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists 





> From: Damien Cassou
> Sent: Wednesday, February 28, 2007 1:51 PM
> 
> 2007/2/28, Ralph Johnson <johnson at cs.uiuc.edu>:
> > On 2/28/07, Damien Cassou <damien.cassou at gmail.com> wrote:
> > > So, do we choose to conform to ansi or to keep compatibility ?
> >
> > This is always a hard question.
> >
> > Try changing it and see what breaks.  If nothing breaks then it is
> > easy to choose to confirm.  If things break then at least we will have
> > a better idea of how hard it will be to change it.
> 
> I think some important classes depend on that behavior: parsers numbers...
> 
> --
> Damien Cassou
> 





More information about the Squeak-dev mailing list