Properties and releasing participants

Hello all,

I have a problem that requires some context and a stream from which data
is read.  There are enough #readFrom: methods floating around that I
didn't want to include the context in the methods.  I might rethink the
latter.

Associating a property with the stream works well.  The snag that I
recently discovered is that some objects are not being gc'd w/o
something similar to #release.  In the spirit of "it can't hurt to ask":
any ideas?  Hopefully some of you have been down this path and can offer
some useful experience.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> I have a problem that requires some context and a stream from which data
> is read.  There are enough #readFrom: methods floating around that I
> didn't want to include the context in the methods.

If you are manipulating a bunch of related data, which includes a stream, why
not create an object (a custom object or a LookupTable) that contains all the
data you want including the stream, and pass that around ?

    -- chris

Chris,

>>I have a problem that requires some context and a stream from which data
>>is read.  There are enough #readFrom: methods floating around that I
>>didn't want to include the context in the methods.
>
>
> If you are manipulating a bunch of related data, which includes a stream, why
> not create an object (a custom object or a LookupTable) that contains all the
> data you want including the stream, and pass that around ?

The main reason is that in most situations, a stream is all one needs.
A couple of the more complicated players need more context, and I didn't
want to burden all of them with the extra step.  Howevever, properties
appear to have added some of their own wrinkles.

Some type of decorator might be in order.  What do you think about
something that is a <readableStream> itself, forwarding those messages
to a contained stream, and holding the additional context?  Such an
object (probably a subclass thereof) could be assembled for each of the
problematic cases.

Another option would be to define #asStreamWithContext or something, and
send that "everywhere", but that would (I suspect) get ugly fast and add
many needless message sends.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Chris, everybody, anybody,

> Some type of decorator might be in order.  What do you think about
> something that is a <readableStream> itself, forwarding those messages
> to a contained stream, and holding the additional context?  Such an
> object (probably a subclass thereof) could be assembled for each of the
> problematic cases.

The decorated stream idea is starting to take a big lead.  If you don't
like the idea, please speak up - I'd rather hear about now than after
learning the hard way ~:0

The short version is that I have a thread synchronization problem that
should take advantage (and test the limits) of an existing hierarchy.  A
slight variant on the decorated stream concept would make that easier,
and would probably also fix the property/release stuff at the same time.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> The decorated stream idea is starting to take a big lead.  If you don't
> like the idea, please speak up - I'd rather hear about now than after
> learning the hard way ~:0

I've nothing against the idea, I'm rather fond of decorators[*].  You may want
to check (with your internal design department ;-) that the objects in question
really should be streams (in the sense of IS-A stream rather than HAS-A
stream), but assuming the answer is yes, then I'd go for it...

I've found streams a little difficult to decorate (a side effect of the
hierarchy design).  It's usually straightforward to create a limited
implementation for a specific purpose, but doing it well in the general case
can be quite frustrating.  (The 'abstract' streams in my 'CU Abstract
Collections' package -- under Miscellanea on my website -- are my attempt to
solve that particular problem.)

One thought, though.  You implied that you are currently using #properties, and
that you were having to remove properties explicitly in order to allow their
values to be GCed.  If I'm understanding you correctly, then that's presumably
because you were holding on to the stream /with/ the #property longer than you
expected, and -- if so -- turning the #property into a full instvar of a
stream-like object won't fix the problem.

    -- chris

([*] though they can get out of hand...)

Chris,

> I've nothing against the idea, I'm rather fond of decorators[*].  You may want
> to check (with your internal design department ;-) that the objects in question
> really should be streams (in the sense of IS-A stream rather than HAS-A
> stream), but assuming the answer is yes, then I'd go for it...

I suspect is-a makes a lot of sense for the same reason I don't want to
use a conversion method - too many places to worry about it.  With that
said, I will reconsider whether there might be a logical entry point to
do such a conversion; there is a composite class that might be able to
do it, and there are factories that might be able to help, though those
objects are not (yet anyway) involved in the reads.  However, I suspect
the nature of it is to take a stream with the rare need for additional
context.


> I've found streams a little difficult to decorate (a side effect of the
> hierarchy design).  It's usually straightforward to create a limited
> implementation for a specific purpose, but doing it well in the general case
> can be quite frustrating.  (The 'abstract' streams in my 'CU Abstract
> Collections' package -- under Miscellanea on my website -- are my attempt to
> solve that particular problem.)

A read stream is enough.  Am I still at risk?


> One thought, though.  You implied that you are currently using #properties, and
> that you were having to remove properties explicitly in order to allow their
> values to be GCed.  If I'm understanding you correctly, then that's presumably
> because you were holding on to the stream /with/ the #property longer than you
> expected, and -- if so -- turning the #property into a full instvar of a
> stream-like object won't fix the problem.

You don't miss much :)  To be honest, I have not ruled it out, but I
suspect that the real problem is that the thing saved as a property has
a read stream (much like a socket has a #readStream), and that the cycle
forms as a result.  That suggests another alternative, which is to send
#readStream to objects that enter, but even that is likely to be ugly -
it's a rich hierarchy.

As an aside, any time something like this starts to bother me, I try to
imagine solving it in C++.  The problem would be just as real, and
trying any solution would be _much_ more painful than in Smalltalk.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> > I've found streams a little difficult to decorate (a side effect of the
> > hierarchy design).  It's usually straightforward to create a limited
> > implementation for a specific purpose, but doing it well in the general
> > case can be quite frustrating.  (The 'abstract' streams in my 'CU
> > Abstract Collections' package -- under Miscellanea on my website -- are
> > my attempt to solve that particular problem.)
>
> A read stream is enough.  Am I still at risk?

"risk" is perhaps rather too strong a word.  I have found it somewhat
problematic to create custom implementations of the /full/ protocol(s)
understood by ReadStreams (including whatever custom extensions are present in
the image).  Mainly because a fair amount of the relevant behaviour is only
defined against concrete classes PositionableStream and ReadStream (though I
should note that OA have been cleaning this up over the last years,
SequencedStream is now fully abstract).

But that's only a problem if you are looking for a general solution.  If all
you want is an object that is enough like a ReadStream for the uses that your
project /actually/ makes of it, then you can create that quite easily, I should
think.  (Personally, I'd be inclined to subclass object and avoid the Stream
hierarchy altogether -- but of course you will have your own preferred way of
approaching this)

    -- chris

Chris,

> But that's only a problem if you are looking for a general solution.  If all
> you want is an object that is enough like a ReadStream for the uses that your
> project /actually/ makes of it, then you can create that quite easily, I should
> think.  

That would be the plan.  The offending packages have fairly extensive
tests.  There would still be concern over the type of contained stream
(analogous to aByteArray readStream in tests vs. aSocket readStream in
real use), but I suspect that a gratuitous smoke test in the real world
would turn up any problems.


 > (Personally, I'd be inclined to subclass object and avoid the Stream
> hierarchy altogether -- but of course you will have your own preferred way of
> approaching this)

By that do you mean making the forwarding stream a subclass of Object?
That is the idea, with help from protocols and unit tests.

This exercise (thanks!!!) combined with some work I did yesterday
suggests another possibility: find an appropriate place to do the
release.  I might see where to do that - better late than never ~:0

Have a good one,

Bil

--
Wilhelm K. Schwab, Ph.D.
[hidden email]