2008/5/17 Craig Latta <craig at netjam.org>:
>
>     Yes. As far as using streams as an example, I never understood why
> support for write-only streams was ever needed. What's wrong with just
> assuming all streams are readable? Then this classic dilemma just goes away.
> It seems to me that whoever wrote the first internal streams implementation
> for Smalltalk simply got that part wrong, and no one questioned it for a
> long time. I wouldn't make this a primary motivating example for traits
> (hopefully there's a better one).
>

There are lot of hardware having a write-only capabilities, yes they
can be bidirectional and software built on top of them can imitate
read/write behavior. A devices like com port or network card are
bidirectional devices which support both reading and writing but this
not means that you can read back what you just written to it, or do
seek.

One example from my real experience. I was involved in a project to
develop VoIp software (like Skype).
I was hired just after point, when main design decisions was made.
A principal design failure was, that communication between parties was
built on a bidirectional stream principles (say two hosts connecting
and starting conversation by exchanging voice data streams).
And when we came to point where we started implementing a 'conference
calls' (when more than two people involved in conversation), it was
become clear to all (not only me, who warned about that ;) ), that it
is better to represent a conversation as a set of independent
listeners and independent media sources.
And you may see an analogy to read/write only streams:  listener is
read only stream, while media source is write-only stream which should
stay decoupled from each other in example above.

>
> -C
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.