PositionnableStream>>peekFor: not standard
Locked
12
12
PositionnableStream>>peekFor: not standard
 
|
Hi,
the method PositionnableStream>>peekFor: does not conform to ANSI. In fact, this method should just test the following element in the stream and verify if it equals the parameter. However, the squeak version go forward in the stream if the objects equals. The comment in squeak is clear about this. So, do we choose to conform to ansi or to keep compatibility ? If I'm implementing a new stream hierarchy that may replace the current one, do I need to keep compatibility or be standard ? Bye -- Damien Cassou |
Re: PositionnableStream>>peekFor: not standard
|
|
On 2/28/07, Damien Cassou <[hidden email]> 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. -Ralph |
Re: PositionnableStream>>peekFor: not standard
|
|
2007/2/28, Ralph Johnson <[hidden email]>:
> On 2/28/07, Damien Cassou <[hidden email]> 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 |
RE: PositionnableStream>>peekFor: not standard
|
|
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 <[hidden email]>: > > On 2/28/07, Damien Cassou <[hidden email]> 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 > |
Re: PositionnableStream>>peekFor: not standard
|
|
In Squeak there was at least a way to indicate a deprecated method. I
saw it. There was a preference to activate notifications of deprecations. This possibility should still exist. Maybe we can: - implement a #peekIf: method with the same source code as current #peekFor: - depreciate #peekFor: method and call #peekIf: from there to keep compatibility - wait one or two releases - change #peekFor: to only peek and conform to standard. What do you think ? -- Damien Cassou |
|
|
In reply to this post by Ralph Johnson
Actually, in this case I'd suggest that we change the standard! In each of
the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, VisualAge, VisualSmalltalk, VisualWorks) the following returns true: ((ReadStream on: 'abc') peekFor: $a; next) = $b. This makes some sense. If you get back what you expect, why ask for it again? Is there an ANSI errata? If not, could we have a wiki page available for such? I have several things to add... James Foster > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Ralph Johnson > Sent: Wednesday, February 28, 2007 10:29 AM > To: The general-purpose Squeak developers list > Subject: Re: PositionnableStream>>peekFor: not standard > > On 2/28/07, Damien Cassou <[hidden email]> 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. > > -Ralph |
RE: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Damien Cassou-3
Damien,
I guess that would work but here are my concerns: First peekFor: is not really deprecated. It's only being marked deprecated so that we can take it back and change its function. Second, if deprecated notification is an option then it's easily ignored. How about we do this? There has been a lot of argument about Squeak being stuck in the mud because we need to keep stability instead of favoring cleaning up the code. Some have argued that we need to burn the disk packs to allow us to move forward. How about a middle ground? With proper organization we could develop an upgrade doc and possibly upgrade tools. It would be much easier to do this now then trying to figure it all out later. I like the idea of adding: <functionalChangeInVersion: 3.10> or: <deprecatedInVersion: 3.10> so we can build tools later. (Pragma allNamed: #functionalChangeVersion: in: MyClass) IF the change is well documented in a highly visible upgrade document, that has a permanent location, and we do our best to point people to that document from many different places, and it is very easy for people (or the release team) to add to the document all deprecated methods and their replacements, or changes in function, THEN I'd say we just change it (including changing all senders), document it, advertise it and move on. What do you think? Ron > From: Damien Cassou > Sent: Wednesday, February 28, 2007 3:36 PM > > In Squeak there was at least a way to indicate a deprecated method. I > saw it. There was a preference to activate notifications of > deprecations. This possibility should still exist. Maybe we can: > > - implement a #peekIf: method with the same source code as current > #peekFor: > - depreciate #peekFor: method and call #peekIf: from there to keep > compatibility > - wait one or two releases > - change #peekFor: to only peek and conform to standard. > > What do you think ? > > -- > Damien Cassou |
RE: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by jgfoster
That's very interesting. It sure seemed wrong to me! Although like I said
it does make some sense. Given that it's consistent in Smalltalk I'd say we leave it. Thanks James! Ron > From: James Foster > Sent: Wednesday, February 28, 2007 4:00 PM > > Actually, in this case I'd suggest that we change the standard! In each of > the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, > VisualAge, VisualSmalltalk, VisualWorks) the following returns true: > > ((ReadStream on: 'abc') peekFor: $a; next) = $b. > > This makes some sense. If you get back what you expect, why ask for it > again? > > Is there an ANSI errata? If not, could we have a wiki page available for > such? I have several things to add... > > James Foster > > > -----Original Message----- > > From: [hidden email] [mailto:squeak-dev- > > [hidden email]] On Behalf Of Ralph Johnson > > Sent: Wednesday, February 28, 2007 10:29 AM > > To: The general-purpose Squeak developers list > > Subject: Re: PositionnableStream>>peekFor: not standard > > > > On 2/28/07, Damien Cassou <[hidden email]> 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. > > > > -Ralph > > > |
Re: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by jgfoster
James Foster a écrit :
> Actually, in this case I'd suggest that we change the standard! In each of > the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, > VisualAge, VisualSmalltalk, VisualWorks) the following returns true: > > ((ReadStream on: 'abc') peekFor: $a; next) = $b. > > This makes some sense. If you get back what you expect, why ask for it > again? > > Is there an ANSI errata? If not, could we have a wiki page available for > such? I have several things to add... > > James Foster > Totally agree, change ANSI peekFor: does peek, and advance if character (or any object) matched. 1) This covers 99% of our needs. 2) If we start periphrasing like peekAndAdvanceIfEqualTo: our small talk will fast become longish and boring. (Why not doWithEveryElement: instead of do: etc...) Nicolas |
Re: PositionnableStream>>peekFor: not standard
|
|
James Foster a écrit :
> Actually, in this case I'd suggest that we change the standard! In > each of > the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, > VisualAge, VisualSmalltalk, VisualWorks) the following returns true: > > ((ReadStream on: 'abc') peekFor: $a; next) = $b. > Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. Nicolas |
Re: PositionnableStream>>peekFor: not standard
|
|
nicolas cellier wrote:
> James Foster a écrit : >> Actually, in this case I'd suggest that we change the standard! In >> each of >> the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, >> VisualAge, VisualSmalltalk, VisualWorks) the following returns true: >> >> ((ReadStream on: 'abc') peekFor: $a; next) = $b. >> > > Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. I can't help but wonder how ANSI ended up with that definition if basically every Smalltalk in existence does it differently. Just one of those "design by committee" decisions? Or perhaps there is a good reason for it that just never made the light of the day? Mostly, the standards committee seemed to have gone with existing notions if there wide agreement on them - peekFor: seems to be one of those cases where the standard went wildly differently and I really wonder why. Cheers, - Andreas |
Re: PositionnableStream>>peekFor: not standard
|
|
Andreas Raab a écrit :
> nicolas cellier wrote: >> James Foster a écrit : >>> Actually, in this case I'd suggest that we change the standard! In >>> each of >>> the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, >>> VisualAge, VisualSmalltalk, VisualWorks) the following returns true: >>> >>> ((ReadStream on: 'abc') peekFor: $a; next) = $b. >>> >> >> Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. > > I can't help but wonder how ANSI ended up with that definition if > basically every Smalltalk in existence does it differently. Just one of > those "design by committee" decisions? Or perhaps there is a good reason > for it that just never made the light of the day? Mostly, the standards > committee seemed to have gone with existing notions if there wide > agreement on them - peekFor: seems to be one of those cases where the > standard went wildly differently and I really wonder why. > > Cheers, > - Andreas > > Who knows... Let us kindly consider this is just an error that only deserve an errata like James suggested Nicolas |
Re: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Andreas.Raab
On 28-Feb-07, at 2:23 PM, Andreas Raab wrote: > peekFor: seems to be one of those cases where the standard went > wildly differently and I really wonder why. Try emailing Glen Krasner; he was one of the major players in writing the standard. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: RBT: Rewind and Break Tape |
RE: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Andreas.Raab
You know I still think it's wrong and should be implemented the way the
standard says. Peek should peek regardless of how it is eventually used and how all of the Smalltalk's implement it. I can't be the only one that saw it didn't work as expected and didn't use it because of that. Notice that there are few senders of peekFor: and lots of senders of peek even though many of the senders of peek are really peek fors. Seems like a me-too implementation issue. I'll give you that the uses of peekFor: in the parsers are very cleaver uses of peekFor: (ex. negative := peekFor: $-. ) and I do get how and why it's implemented the way it is but I still won't use it. I do agree, even though I won't use it, that it should be left the way it is since it is consistent with all the other Smalltalks. I wonder how many other standards are not followed. Did anyone check #isEmpty on PositionableStream? Ron Teitelbaum > From: Andreas Raab > Sent: Wednesday, February 28, 2007 5:23 PM > > nicolas cellier wrote: > > James Foster a écrit : > >> Actually, in this case I'd suggest that we change the standard! In > >> each of > >> the six Smalltalk dialects I have available (Dolphin, GemStone, Squeak, > >> VisualAge, VisualSmalltalk, VisualWorks) the following returns true: > >> > >> ((ReadStream on: 'abc') peekFor: $a; next) = $b. > >> > > > > Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. > > I can't help but wonder how ANSI ended up with that definition if > basically every Smalltalk in existence does it differently. Just one of > those "design by committee" decisions? Or perhaps there is a good reason > for it that just never made the light of the day? Mostly, the standards > committee seemed to have gone with existing notions if there wide > agreement on them - peekFor: seems to be one of those cases where the > standard went wildly differently and I really wonder why. > > Cheers, > - Andreas > |
RE: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Nicolas Cellier-3
Yes, in this case, change ANSI.
And also have all the Smalltalk implementations add a comment to the #peekFor: method stating the Smalltalk community has decided the standard is wrong, and in conflict with established practice. --Alan <Nicolas Cellier> James Foster a écrit : > Actually, in this case I'd suggest that we change the standard! In > each of the six Smalltalk dialects I have available (Dolphin, > GemStone, Squeak, VisualAge, VisualSmalltalk, VisualWorks) the following returns true: > > ((ReadStream on: 'abc') peekFor: $a; next) = $b. > > This makes some sense. If you get back what you expect, why ask for it > again? > > Is there an ANSI errata? If not, could we have a wiki page available > for such? I have several things to add... > > James Foster > Totally agree, change ANSI </Nicolas Cellier> |
Re: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Andreas.Raab
I'd guess it was just a nod to the rest of the world. There are a lot of peeks in a lot of stream implementations out there, and pretty much all of them leave the result in the stream. When I see peek in the name of a stream operation, my hindbrain reads it as non-consuming. Sometimes there are peeks that alter the stream - operations that consume everything up to - but not including - a sought-after character. But the thing you're peeking at is unaffected; that's a very common convention about what the word 'peek' conveys in the name of a stream operation. - b > I can't help but wonder how ANSI ended up with that definition if > basically every Smalltalk in existence does it differently. Just > one of those "design by committee" decisions? Or perhaps there is a > good reason for it that just never made the light of the day? > Mostly, the standards committee seemed to have gone with existing > notions if there wide agreement on them - peekFor: seems to be one > of those cases where the standard went wildly differently and I > really wonder why. > > Cheers, > - Andreas > |
Re: PositionnableStream>>peekFor: not standard
|
|
As usually, we all have different opinions :-)
Since most Smalltalks have the same #peekFor: implementation, I won't touch it. However, I will explicitely explain the problem in the comment and write tests. If some of you want, I can create a new method with the standard implementation. You just need to give me a name. I will write tests and a comment. -- Damien Cassou |
Re: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Ron Teitelbaum
But why should there be a method #peekFor: if it does not more than
#peek and #=? These two would do the same stream peekFor: $a stream peek = $a That would be strange. I don't find the name "peek" offensive in its current meaning. OTOH, if there was a better name for what it does, I'd not be violently opposed to changing it. As an aside, there is a similar method: stream match: 'a' would do the same as the "advancing" #peekFor: but for a collection. - Bert - On Mar 1, 2007, at 1:57 , Ron Teitelbaum wrote: > You know I still think it's wrong and should be implemented the way > the > standard says. Peek should peek regardless of how it is eventually > used and > how all of the Smalltalk's implement it. I can't be the only one > that saw > it didn't work as expected and didn't use it because of that. > Notice that > there are few senders of peekFor: and lots of senders of peek even > though > many of the senders of peek are really peek fors. Seems like a me-too > implementation issue. > > I'll give you that the uses of peekFor: in the parsers are very > cleaver uses > of peekFor: (ex. negative := peekFor: $-. ) and I do get how and > why it's > implemented the way it is but I still won't use it. > > I do agree, even though I won't use it, that it should be left the > way it is > since it is consistent with all the other Smalltalks. I wonder how > many > other standards are not followed. Did anyone check #isEmpty on > PositionableStream? > > Ron Teitelbaum > > >> From: Andreas Raab >> Sent: Wednesday, February 28, 2007 5:23 PM >> >> nicolas cellier wrote: >>> James Foster a écrit : >>>> Actually, in this case I'd suggest that we change the standard! In >>>> each of >>>> the six Smalltalk dialects I have available (Dolphin, GemStone, >>>> Squeak, >>>> VisualAge, VisualSmalltalk, VisualWorks) the following returns >>>> true: >>>> >>>> ((ReadStream on: 'abc') peekFor: $a; next) = $b. >>>> >>> >>> Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. >> >> I can't help but wonder how ANSI ended up with that definition if >> basically every Smalltalk in existence does it differently. Just >> one of >> those "design by committee" decisions? Or perhaps there is a good >> reason >> for it that just never made the light of the day? Mostly, the >> standards >> committee seemed to have gone with existing notions if there wide >> agreement on them - peekFor: seems to be one of those cases where the >> standard went wildly differently and I really wonder why. >> >> Cheers, >> - Andreas >> > > > |
Re: PositionnableStream>>peekFor: not standard
|
|
On Thu, 01 Mar 2007 12:24:03 +0100, Bert Freudenberg wrote:
> But why should there be a method #peekFor: if it does not more than > #peek and #=? These two would do the same > > stream peekFor: $a > stream peek = $a > > That would be strange. +1 don't reimplement the implemented. Talk small and do great things. > I don't find the name "peek" offensive in its current meaning. /Klaus > OTOH, if there was a better name for what it does, I'd not be violently > opposed to changing it. As an aside, there is a similar method: > > stream match: 'a' > > would do the same as the "advancing" #peekFor: but for a collection. > > - Bert - > > On Mar 1, 2007, at 1:57 , Ron Teitelbaum wrote: > >> You know I still think it's wrong and should be implemented the way the >> standard says. Peek should peek regardless of how it is eventually >> used and >> how all of the Smalltalk's implement it. I can't be the only one that >> saw >> it didn't work as expected and didn't use it because of that. Notice >> that >> there are few senders of peekFor: and lots of senders of peek even >> though >> many of the senders of peek are really peek fors. Seems like a me-too >> implementation issue. >> >> I'll give you that the uses of peekFor: in the parsers are very cleaver >> uses >> of peekFor: (ex. negative := peekFor: $-. ) and I do get how and why >> it's >> implemented the way it is but I still won't use it. >> >> I do agree, even though I won't use it, that it should be left the way >> it is >> since it is consistent with all the other Smalltalks. I wonder how many >> other standards are not followed. Did anyone check #isEmpty on >> PositionableStream? >> >> Ron Teitelbaum >> >> >>> From: Andreas Raab >>> Sent: Wednesday, February 28, 2007 5:23 PM >>> >>> nicolas cellier wrote: >>>> James Foster a écrit : >>>>> Actually, in this case I'd suggest that we change the standard! In >>>>> each of >>>>> the six Smalltalk dialects I have available (Dolphin, GemStone, >>>>> Squeak, >>>>> VisualAge, VisualSmalltalk, VisualWorks) the following returns true: >>>>> >>>>> ((ReadStream on: 'abc') peekFor: $a; next) = $b. >>>>> >>>> >>>> Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. >>> >>> I can't help but wonder how ANSI ended up with that definition if >>> basically every Smalltalk in existence does it differently. Just one of >>> those "design by committee" decisions? Or perhaps there is a good >>> reason >>> for it that just never made the light of the day? Mostly, the standards >>> committee seemed to have gone with existing notions if there wide >>> agreement on them - peekFor: seems to be one of those cases where the >>> standard went wildly differently and I really wonder why. >>> >>> Cheers, >>> - Andreas >>> >> >> >> > > > > |
RE: PositionnableStream>>peekFor: not standard
|
|
In reply to this post by Bert Freudenberg
Hi Bert,
I get that #peekFor: that doesn't advance is the same as #peek #=. That's why it was easy for me to get what I was looking for without using peekFor: . I also agree that we could leave it the way it is, since it is supported in all smalltalks in its current implementation. I suppose my objection is just a personal taste issue. I won't use it because it just makes more sense to me to use #peek #= then #next. Although I did think isNegative := aStream peekFor: $-. was very nice and did make the code cleaner. By the way match is not really the same: ('abc' copy readStream) match: 'b'; next => $c Since 'a' is not matched it advances until we find the collection. This is really different from peek = $a since it flys past the next element to find 'b'. Ron Teitelbaum > From: Bert Freudenberg > Sent: Thursday, March 01, 2007 6:24 AM > > But why should there be a method #peekFor: if it does not more than > #peek and #=? These two would do the same > > stream peekFor: $a > stream peek = $a > > That would be strange. > > I don't find the name "peek" offensive in its current meaning. OTOH, > if there was a better name for what it does, I'd not be violently > opposed to changing it. As an aside, there is a similar method: > > stream match: 'a' > > would do the same as the "advancing" #peekFor: but for a collection. > > - Bert - > > On Mar 1, 2007, at 1:57 , Ron Teitelbaum wrote: > > > You know I still think it's wrong and should be implemented the way > > the > > standard says. Peek should peek regardless of how it is eventually > > used and > > how all of the Smalltalk's implement it. I can't be the only one > > that saw > > it didn't work as expected and didn't use it because of that. > > Notice that > > there are few senders of peekFor: and lots of senders of peek even > > though > > many of the senders of peek are really peek fors. Seems like a me-too > > implementation issue. > > > > I'll give you that the uses of peekFor: in the parsers are very > > cleaver uses > > of peekFor: (ex. negative := peekFor: $-. ) and I do get how and > > why it's > > implemented the way it is but I still won't use it. > > > > I do agree, even though I won't use it, that it should be left the > > way it is > > since it is consistent with all the other Smalltalks. I wonder how > > many > > other standards are not followed. Did anyone check #isEmpty on > > PositionableStream? > > > > Ron Teitelbaum > > > > > >> From: Andreas Raab > >> Sent: Wednesday, February 28, 2007 5:23 PM > >> > >> nicolas cellier wrote: > >>> James Foster a écrit : > >>>> Actually, in this case I'd suggest that we change the standard! In > >>>> each of > >>>> the six Smalltalk dialects I have available (Dolphin, GemStone, > >>>> Squeak, > >>>> VisualAge, VisualSmalltalk, VisualWorks) the following returns > >>>> true: > >>>> > >>>> ((ReadStream on: 'abc') peekFor: $a; next) = $b. > >>>> > >>> > >>> Also add stx (Smalltalk-X) and gst (GNU Smalltalk) to the list. > >> > >> I can't help but wonder how ANSI ended up with that definition if > >> basically every Smalltalk in existence does it differently. Just > >> one of > >> those "design by committee" decisions? Or perhaps there is a good > >> reason > >> for it that just never made the light of the day? Mostly, the > >> standards > >> committee seemed to have gone with existing notions if there wide > >> agreement on them - peekFor: seems to be one of those cases where the > >> standard went wildly differently and I really wonder why. > >> > >> Cheers, > >> - Andreas > >> > > > > > > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |