[Pharo-dev] In-memory FileSystem write streams not being polymorphic

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Nov 13 14:17:15 EST 2013


Exactly, every specialized stream has its specialized API and/or
specialized implementation.
File streams don't even have a name, because they need not to.
You can browse XTFileReadStream and XTFileWriteStream, you won't find such
thing.
The file has a name, the stream does not need any.
Before adding anything to a stream, ask first, why am i going to need this?


2013/11/13 Frank Shearar <frank.shearar at gmail.com>

> On 13 November 2013 16:48, Chris Muller <asqueaker at gmail.com> wrote:
> > I know nothing about Xtreams but, IMO, this obsession with sterility
> > borders on mental illness.
> >
> > "All sort of un-needed complexity?"  That's overstating it a bit,
> > don't you think?
> >
> > So you must really feel stressed that ALL Object's, in fact, have a
> > #name, huh?  I admit this seems to push the limits but...
> >
> > what's the point of having any kind of different streams at all then?
> > It's the _differences_ between them that makes composing them useful.
> > Compression, encryption, filtering, sockets, files, circular, etc.
> > You think you'll be able to do all that and get away with all of them
> > having exactly the same API?
>
> They don't have the same API. And they shouldn't. And that's Nicolas'
> whole point. A Stream does not have a name (nor should it - what's the
> name of the compressed output of an audio stream from your
> microphone?). A FileStream can extend this API, and that's fine. But
> keep that out of the Stream API.
>
> So Nicolas is arguing that _difference_ should be reflected in the
> API. File streams have names, but generic streams do not.
>
> As it happens, Xtreams takes a very disciplined approach to this. Some
> streams have positions, and so you can go back. Some can't. This is
> reflected in the API. This is good.
>
> > IMHO working around that, passing extra objects around, sounds more
> > stressful than letting a stream on a _file_ know its filename..
>
> Mu. Streams have no names. File streams have names.
>
> frank
>
> >> If it really need it, the application certainly can retrieve the name
> from a higher level object (a FIleReference, FileDirectory or whatever).
> >
> > How does that solution allow uniformity in stream-using code?
> >
> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier
> > <nicolas.cellier.aka.nice at gmail.com> wrote:
> >> Yes, a Wrapper would provide the legacy API.
> >>
> >> And yes, the name of a stream should better not be part of the API.
> >> Most stream don't have a name, and adding such API adds all sort of
> >> un-needed complexity.
> >> It's an internal detail that can eventually help for reporting error if
> >> accessible, but nothing more.
> >>
> >> If it really need it, the application certainly can retrieve the name
> from a
> >> higher level object (a FIleReference, FileDirectory or whatever).
> >>
> >>
> >> 2013/11/13 Chris Muller <asqueaker at gmail.com>
> >>>
> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
> >>> <nicolas.cellier.aka.nice at gmail.com> wrote:
> >>> > It's just a matter of selecting a strategy. I've proposed two:
> >>> > A) create a wrapper class for legacy Stream compatibility selectors
> >>> > B) create extensions for Legacy Stream compatibility selectors
> >>> > My preference goes to A)
> >>>
> >>> By wrappers you mean the Xtreams are the innards doing the work and
> >>> the wrappers providing the legacy API?
> >>>
> >>> This would be a great way to test Xtreams.
> >>>
> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek
> upTo:
> >>> > ...), otherwise we will import all the cruft in Xtream and would go
> back
> >>> > to
> >>> > our starting point...
> >>> > Once the minimal support written (a few hours should be enough), we
> >>> > should
> >>> > gradually switch each every legacy Stream usage -> Xtream.
> >>> >
> >>> > An area which require more work is those Streams that have mixed
> >>> > conventions
> >>> > (one portion is interpreted as text, another as binary).
> >>> > In theory that's easy, we just have two streams and they both wrap
> on a
> >>> > low
> >>> > level binary stream, but that means we have to be very cautious with
> >>> > buffers
> >>> > and caches.
> >>> >
> >>> > Another area of work is usage of ugly selectors like name (we try to
> >>> > access
> >>> > the file name from the Stream API, arghh). Those usages are bad and
> >>> > require
> >>> > a rewrite.
> >>>
> >>> Are you saying a FileStream knowing its #name or #filename is bad?
> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131113/07bb672a/attachment-0002.html>


More information about the Pharo-dev mailing list