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@cs.uiuc.edu:
On 2/28/07, Damien Cassou damien.cassou@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