On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe, <s...@stfx.eu> wrote:

>
>
> > On 9 May 2018, at 13:41, Thierry Goubier <thierry.goub...@gmail.com>
> wrote:
> >
> > 2018-05-09 13:14 GMT+02:00 Sven Van Caekenberghe <s...@stfx.eu>:
> >> You mean you made a subclass of StandardFilestream yourself ?
> >
> > There are a few subclasses of StandardFileStream in OSProcess:
> > AttachableFileStream, AsyncFileReadStream and
> > BufferedAsyncFileReadStream. They will need to be ported.
> >
> >> If yes, can you describe briefly why you did so ?
> >
> > As far as my analysis go, AttachableFileStream refers to and
> > manipulates the underlying ioHandle of a unix pipe stream,
> > AsyncFileReadStream interacts with the asynchronous io extensions of
> > the vm to observe that io handle, and a BufferedAsyncFileReadStream
> > add a thread-safe, buffered, blocking API for smalltalk processe on
> > top.
>
> Yes, they will have to be ported.
>
> If it were me (but I haven't looked at the code) I would not inherit from
> those classes, but from a simpler Stream class, possibly even none. The
> stream API is actually quite small (or it should be).
>
> Inheritance is an implementation technique, inheriting from a complex
> class can be hard, unless the superclass was really designed with that
> purpose.
>
> All this, IMHO.
>


I agree that these classes will need to be ported, just a little food
for thought:

I believe OSProcess is currently common between Squeak and Pharo - this
porting will require that OSProcess is forked for Pharo, so the two
implementations will start to diverge unless someone actively keeps them
in sync.  (Please don't read this as a negative judgement, it is
just a statement of my understanding of the situation).


There are a number of plugin primitives that Dave added to OSProcess
because FilePlugin didn't meet his requirements.  Some of the recent
changes made to FilePlugin reduce the need for additional primitives (it
is possible to connect to an existing file or file descriptor, #atEnd
works for pipes), and I think there are additional enhancements that can
be made which would reduce the number even further (mark files as
non-blocking) (but I haven't looked in to it properly and would want to
get Dave's input first).


Cheers,
Alistair

Reply via email to