Hi Blair,
> Sorry about that. It should have been deprecated rather than removed,
since
> it was a public method.
No harm done. I noticed it only after realizing that I could capture the
exact set of loose methods that I file in to a D5 image rather than working
at it each time. Migrate now helps with transferring options perferences.
At some point, I'll have to stop fiddling with it and update it for D5.
One remaining problem is whether to file in loose methods before or after
installing packages. A couple of my physiologic monitor interface packages
do some binary stream I/O using methods that I have kept loose because they
might collide with the base system. The end result is that the packages
don't load happily unless the methods are present. The bad news is that
some of my loose methods alter classes that don't exist until after I load
packages =:0
Zooming out, this sounds a lot like a need for conditionally filing in code;
somebody posted something recently that sounded promising, but, I didn't
have time to look at it when I saw it.. I _think_ what I want is a way to
have code iterate a bunch of chunks to see whether or not they collide and
file them in if they don't, and probably open up something like Ian's chunk
browser on the ones that have problems. Of course, there's still the
before/after load problem; things that don't collide and file in early might
cause problems loading packages later.
> You should use a ChunkSourceFiler.
Something like this??
| out |
out := String writeStream.
(ChunkSourceFiler on: out)
fileOutMessages: (Array with:#asBSTR )
ofBehavior:String.
out contents.
Speaking of public vs. private, have a look at
SourceFiler>>fileOutExpression: and some methods near it - they say they are
private (in their comments) but are categorized as public ~:0
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
