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
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.
-Ralph
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...
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
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,
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
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: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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 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.
-Ralph
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: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] 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 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.
-Ralph
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
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
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
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
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RBT: Rewind and Break Tape
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
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
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
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
On Mar 1, 2007, at 15:44 , Ron Teitelbaum wrote:
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'.
Ah, you're right.
- Bert -
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
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.
You don't mean writing tests that are red on purpose I hope. :)
From: "Damien Cassou" damien.cassou@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: PositionnableStream>>peekFor: not standard Date: Thu, 1 Mar 2007 11:12:52 +0100
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
_________________________________________________________________ Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE. http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline
I mean writing tests verifying the behavior I choosed :-)
2007/3/6, J J azreal1977@hotmail.com:
You don't mean writing tests that are red on purpose I hope. :)
From: "Damien Cassou" damien.cassou@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: PositionnableStream>>peekFor: not standard Date: Thu, 1 Mar 2007 11:12:52 +0100
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
Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE. http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline
does somebody has the latest version of the standard because the version we have is a beta from 1993? After indeed this is strange that with such a consensus they got that because on the other part they made a good job.
Stef
On 28 févr. 07, at 23:23, Andreas Raab wrote:
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
The final standard is copyrighted and not freely available on the web.
gettableStream>>peek is described as follows: "Returns the first object in the receiver's future sequence values. The object is not removed from the future sequence values. The returned object must conform to the receiver's sequence value type. Returns nil if the receiver has no future sequence values. The return value will also be nil if the first future sequence object is nil."
gettableStream>>peekFor: is described as follows: "Returns the result of sending #= to the first object in the receiver's future sequence values with anObject as the argument. Returns false if the receiver has no future sequence values."
Note that while #peek explicitly says that the object is not removed, the #peekFor: description does not discuss this question at all. To argue that advancing the position is not standard is to argue from silence. I'd say that the much better assumption is that this was simply an oversight and that the intent of the committee was to document the universal implementation of this method. (Note that the draft standard was widely distributed and those of us following comp.lang.smalltalk at the time had a chance to catch this omission. Calling this an oversight is not intended as a criticism of those who worked quite hard on a generally very useful document.)
James Foster
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of stephane ducasse Sent: Thursday, March 01, 2007 1:56 PM To: The general-purpose Squeak developers list Subject: Re: PositionnableStream>>peekFor: not standard
does somebody has the latest version of the standard because the version we have is a beta from 1993? After indeed this is strange that with such a consensus they got that because on the other part they made a good job.
Stef
On 2 mars 07, at 01:26, James Foster wrote:
The final standard is copyrighted and not freely available on the web.
But could we get it via an obscure place :)
gettableStream>>peek is described as follows: "Returns the first object in the receiver's future sequence values. The object is not removed from the future sequence values. The returned object must conform to the receiver's sequence value type. Returns nil if the receiver has no future sequence values. The return value will also be nil if the first future sequence object is nil."
gettableStream>>peekFor: is described as follows: "Returns the result of sending #= to the first object in the receiver's future sequence values with anObject as the argument. Returns false if the receiver has no future sequence values."
Note that while #peek explicitly says that the object is not removed, the #peekFor: description does not discuss this question at all. To argue that advancing the position is not standard is to argue from silence. I'd say that the much better assumption is that this was simply an oversight and that the intent of the committee was to document the universal implementation of this method. (Note that the draft standard was widely distributed and those of us following comp.lang.smalltalk at the time had a chance to catch this omission. Calling this an oversight is not intended as a criticism of those who worked quite hard on a generally very useful document.)
James Foster
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak- dev- bounces@lists.squeakfoundation.org] On Behalf Of stephane ducasse Sent: Thursday, March 01, 2007 1:56 PM To: The general-purpose Squeak developers list Subject: Re: PositionnableStream>>peekFor: not standard
does somebody has the latest version of the standard because the version we have is a beta from 1993? After indeed this is strange that with such a consensus they got that because on the other part they made a good job.
Stef
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>
squeak-dev@lists.squeakfoundation.org
-
Alan Lovejoy -
Andreas Raab -
Bert Freudenberg -
brad fowlow -
Damien Cassou -
J J -
James Foster -
Klaus D. Witzel -
nicolas cellier -
Ralph Johnson -
Ron Teitelbaum -
stephane ducasse -
tim Rowledge