Few more words about Xtreams

a) A BufferedXtream
can be implemented ultimately as a wrapper stream, so any stream can
be buffered , using

Xtream>>buffered
   ^ self buffered: self preferredBufferSize

Xtream>>buffered: aBufferSize
   ^ (self wrapWith: BufferedXtream) bufferSize: aBufferSize

Xtream>>preferredBufferSize
  ^ 1024

I think there should be an abstract WrapperXtream, from which you can
inherit various kinds of wrappers, like buffering, conversion etc etc.

b) An ascii/binary mode should be deprecated.

The rationale is:
 generic streams, as well as Collections can't say anything about
nature of elements they working with. It could be anyting, like stream
of collections, or stream of arbitrary objects.
Introducing modes at such basic level implying that all streams should
support either of them, and adding unwanted limiting factors and
complexity.
Its not a problem for more specific streams (like file/socket based
ones) to implement these modes (or any other modes) in more robust
manner. But i strongly suggesting to not introduce any modes in base
class(es).
Moreover, a different streams, potentially could support many various
modes they like (compressed, encrypted etc etc). Marking out
ascii/binary modes seems like a discrimination.

But,  for backwards compatibility, we could use wrappers to support
these modes:

Xtream>>ascii
   ^ self wrapWith: AsciiWrapper

AsciiWrapper>>ascii
  ^ self

and by analogy:

Xtream>>binary
   ^ self wrapWith: BinaryWrapper

BinaryWrapper>>binary
   ^ self

this gives us a freedom for any streams to not care about supporting
these modes explicitly, and in case if they care, they could implement
these messages differently.

c) species.
A use of #contentsSpecies again, introducing a limiting factor,
suggesting that all stream elements is going to be of same kind which
could be put into special collection, which can hold only elements of
specific kind like ByteArray or String.

This message used primarily in conjunction with
#readInto:startingAt:count: and #next:putAll:startingAt: for batch
reads/writes
which heavily depending on passing right collection type (you can't
pass OrderedCollection or Set ;).

My own preference is not _asking_ stream (or collection) for species
of its element, but tell it to allocate the buffer (collection) of the
kind it prefers , with given size.
I.e. instead of:

myBuffer := stream contentsSpecies ofSize: 1000.

use:

myBuffer := stream allocateBufferOfSize: 1000.

Then, in most cases, you (as user) would never want to know the
species of elements for a stream, and should not care about allocating
them and knowing their class!

This is one of the patterns i found more flexible and trying to stick
with it everywhere i can. Instead of using:

someClass := object fooClass.

and then, somewhere use:

thing := someClass new.

i using:

thing := object newThing.

Because, by answering a class, you losing a control of the creation
and proper initialization of these instances and by putting this
responsibility onto user, obviously you opening a space for errors.

A simple example, suppose you want to build a tree. As usual, you
giving the user a way to create new nodes, by exposing the class he
should use to create them:

TreeNode>>nodeClass
  ^ TreeNode

now, a user, to create a subnode should do things like:

newNode := node nodeClass new.
newNode parent: node.

While, if you just give a simple #newChild

TreeNode>>newChild
  ^ self class new parent: self

then, user won't care about proper initialization and write just:

newNode := node newChild.

which is more concise, not requires to use intermediate value (node
class) and much more error safe.

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project