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] |
Free forum by Nabble | Edit this page |