[squeak-dev] Xtreams file handles

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Aug 13 07:31:10 UTC 2011

Hmmm, hard to remember...
I started from a previous work of David Lewis.
I think the main reason of the indirection was to connect
- either a class with just an obfuscated handle - see (IOHandle
- or a class exposing structural details of the handle ByteArray known
by the VM - I presume for debug purposes

Then I stripped out the classes exposing details, and only XTIOHandle
now does not seem that usefull indeed...


2011/8/13 Colin Putney <colin at wiresong.com>:
> Hi folks,
> This is addressed mainly to Martin Kobetic and Nicholas Cellier,
> who've done the Squeak port of Xtreams from VisualWorks, but I thought
> I'd post here in case anybody else has an opinion to share.
> I've been working on integrating Filesystem and Xtreams, and I'm a bit
> puzzled by the XTExternalResourceHandle hierarchy. In particular, I
> can't figure out why XTIOHandle exists. It seems to have functionality
> needed by XTIOSocketHandle, plus some indirection for hiding which
> classes are used for file or socket handles, even though there's only
> one choice for either of those. I'm guessing this has to do with the
> need for Xtreams-Terminals to be VW-compatible, and that this
> hierarchy is needed on VW.
> What I need to do is create different versions of XTIOFileHandle that
> can provide access to data in alternate filesystems - in-image, inside
> a zip file, on a remote host etc. Ideally, I'd extract the primitives
> into a separate object, and provide alternate sets of "primitives" for
> non-native filesystems. I don't want to get into changing things
> without understanding the status quo, though.
> Thoughts?
> Colin

More information about the Squeak-dev mailing list