[ANSI-Smalltalk] #contents on <collectionStream>

[cstb]

At 03:00 PM 10/18/2008, you wrote:
>cstb wrote:
>> At 12:14 AM 10/16/2008, Paulo wrote:
>>> In the standard, the definition of #contents for <WriteStream> comes
>>>from <collectionStream> so that this:
>>>   (WriteStream on: String new) nextPutAll: 'abc'; skip: -1;
>>>      contents
>>>
>>> should "return a collection that contains the receiver's past and future
>>> sequence values, in order", i.e. 'abc'.  To me it makes more sense that
>>> it returns 'ab'.
>>>
>>> Opinions?
>> 
>> 
>> It would be nice if the standard was 
>> for <collectionStream> to provide both
>> 
>>         contents        ->      upTo: readLimit
>> and
>>         currentContents ->      upTo: position
>
>Let's try however to follow current practice and not invent new selectors.


Paolo,

As far as I know, current practice is (mostly):

    the single selector
        #contents
    which for readable streams answers 
        self upTo: readLimit
    and for writeable streams answers
        self upTo: position

which you say makes more sense
than the way the standard says to do it.

And I happen to agree, but there are problems,
such as the fact that ReadWriteStreams have both
the aforementioned properties -- here the resolution
which makes the most sense depends on context.

I have, up to now, resolved said ambiguity
in favor of the readable property, i.e.

    ReadWriteStream #contents answers
        self upTo: readLimit.

I've also added the selector #currentContents,
which provides the opposite resolution:

    for WriteStream and ReadWriteStream answering
        self upTo: position
    but otherwise (i.e. for read-only streams) answering
        self upTo: readLimit

which takes care of those 'other contexts', and yet
doesn't conflict with, or require alteration of,
anything related to/relying on 'current practice'.


**But**


it seems to me that

> for <collectionStream> to provide both
> 
>         contents        ->      upTo: readLimit
> and
>         currentContents ->      upTo: position

is actually a better solution,
because it is simple and direct,
*even though* it differs from
current practice, and would require
(simple) changes to (some) existing
code -- code which, as it happens,
also contradicts the current standard.

Seems like a reasonable time, to me,
to let 'non-standard' cancel out 'current practice'
and 'do the right thing' for future practitioners.

But that's just my opinion...

Now, as for the 'and not invent new selectors' bit --
whatever the mystery disease is that seems to give
people an irrational fear of 'new selectors',
I seem to be immune - I'm just not getting it?



Regards,

-Jim