Smalltalk › Squeak › Squeak - Dev

New SqueakMap

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Joshua Gargus-2

Re: Roles of FileStream (was: Re: New SqueakMap)

Oops, I was referring to the magical perfect SmartRefStream in my
head, not the one we actually have :-) Thanks for the correction.

Josh

On Apr 12, 2006, at 5:25 PM, Yoshiki Ohshima wrote:

> Josh,
>
>> It seems to me that character-oriented streams (and any other streams
>> that deal with structured data) should be layered on top of byte-
>> oriented streams, as is done by SmartRefStream (through its
>> superclass, DataStream). A SmartRefStream doesn't care whether it's
>> ultimately reading from / writing to a buffer in memory, from a file,
>> or a network socket connection; that's the responsibility of its
>> 'byteStream'.
>
> Almost, yes. Just the fact that SmarRefStream sends #ascii (old
> day's #text, I consider) and #binary and sometimes it reads some
> encoded text from byteStream suggests it is overdue of refactoring.
>
> -- Yoshiki
>
>

Yoshiki Ohshima

Re: Roles of FileStream (was: Re: New SqueakMap)

Josh,

> Oops, I was referring to the magical perfect SmartRefStream in my
> head, not the one we actually have :-) Thanks for the correction.

If the code has "self flag: #bobconv", everything can happen, hehe.

-- Yoshiki

Martin Wirblat

Re: New SqueakMap

In reply to this post by Yoshiki Ohshima

Yoshiki Ohshima wrote:

>
>>That FileStream oldFileNamed: 'xyz.gif' assumes that xyz.gif is a text
>>file of UFT-8 format looks to me like the principle of the biggest
>>surprise ;)
>
>
> Opening a .gif file as a text file with *any* encoding (including
> non-conversion latin1) is logically wrong anyway... So this example
> may not tell us anything^^;
>
>

Yoshiki,

as Andreas noted you indeed seem to think that FileStream is or should
be a text file stream. Well, I think otherwise. There are myriads of
other structured data types than text and that means that raw byte
handling is different from all of them, because it is their base.

The name FileStream does not specify the contents of the file and thus
it is natural to think of it as the underlying and unspecified byte-handler.

Regards,
Martin

Yoshiki Ohshima

FileStream encoding (Re: New SqueakMap)

Martin,

> as Andreas noted you indeed seem to think that FileStream is or should
> be a text file stream.

It is not that simple.

* Today, it is both #text and #binary in Squeak, anyway.
* If we talk about its default, Squeak's default has been text and
code built around assumes that. (So, in a sense, it
is a text file stream by default.)
* Strictly speaking, it is not logically correct to open a .gif file
as a text stream with any encoding conversion, including no-convertion.
* (The Stream chops off the malformed data is different issue.)
* For mid- and longer term, separate the responsibility is a good
thing. We'll have two or more things, perhaps one is a wrapper
stream of another so the question whether "it" is what or not will
(hopefully) become an unissue.

> Well, I think otherwise. There are myriads of
> other structured data types than text and that means that raw byte
> handling is different from all of them, because it is their base.

I'm not disagreeing with that.

> The name FileStream does not specify the contents of the file and thus
> it is natural to think of it as the underlying and unspecified byte-handler.

I'm not entirely sure about your suggestion. Are you suggesting:

1 to change the default soon?
2 to change it to #binary to be a unspecified byte-handler?
3 to change it to #text and no-conversion, as Göran?
4 or, just stating it should be so?

I agree with 4 in a sense that the thing at the bottom is bytes. For
3, not so sure. For 1 and 2, I would disagree.

-- Yoshiki