Stef,
That sounds fine, but I would want Damien to be involved. I would also
like to discuss the pros and cons of a facade such as
ReadStream class>>on:aCollection
^aCollection readStream.
which I _think_ can be readily adapted to instantiate Nile streams.
There would be a similar trick for write streams.
My thought was to patch things until streams came up on the milestones
list. If you are finding streams are worse off than you thought and
want to move it up, that's fine too. I'm happy to help.
Bill
Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254
Email: [EMAIL PROTECTED]
Tel: (352) 846-1285
FAX: (352) 392-7029
>>> [EMAIL PROTECTED] 07/20/08 11:36 AM >>>
On Jul 19, 2008, at 4:18 PM, Bill Schwab wrote:
> Stef,
>
> The streams are a mess, and the more I work with them, the more I
> understand the desire to replace them with Nile. For now, I am simply
> inserting some methods that behave well (work when they should, raise
> errors when they should) to allow me to begin doing some real work.
So if you can I would suggest you to use Nile and to enhance it.
We should not try to fix too much Stream.
> My view is that I can always add helper classes and methods as needed.
> Whether that gets around fragile design (#nextOne) or is a one-place
> fix
> for the myriad times I open a file, it can always be rewritten to work
> with whatever we create.
>
> URIs make sense. I have never been happy with the ways I split and
> combine paths, so those things will have to be rewritten, especially
> since they are Windows-specific.
Mike showed me the network cleaning he did. But we got problem to export
and load it again (since the system needed itsefl to load it).
Hence my remark on atomic loading.
Stef
>
>
> Bill
>
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: [EMAIL PROTECTED]
> Tel: (352) 846-1285
> FAX: (352) 392-7029
>
>>>> [EMAIL PROTECTED] 07/19/08 5:49 AM >>>
>
> On Jul 18, 2008, at 5:01 PM, Bill Schwab wrote:
>
>> Stef,
>>
>> I do not doubt that the image is littered with such problems. On
>> several occasions, I lost 10-15 minutes tracking down errors that
>> resulted from unopened files. It is all a continuation of my streams
>> "rant" (a well-intentioned one, of course).
>>
>> Meaning no disrespect to the milestones (in particular, streams being
>> slated for the future), I have undertaken an effort similar to what
>> you
>> propose: putting an end to silent failures and lack of protection.
>> As a
>> streams addict, I need stable semantics, and have thus embarked on my
>> #nextOne, #nextMany:, etc. solution to reaching that goal. It also
>> became clear that FileStream was quite unfriendly, so I started
>> adding
>> Dolphin-compatible methods, at least to a point. My primary goal is
>> to
>> have errors arise when appropriate vs. waiting for
>> potentially/apparently disconnected collateral damage to occur.
>
> I have the impression that FileStream should be patched but also
> just rewritten from scratch. I was discussing with mike about the
> use of
> URI in sophie. He told me that they got a really nice solution which
> was offering
> cross platform real portability
>>
>> Dolphin's semantics will not be completely appropriate for Squeak,
>> because there are OS (in)dependencies to consider. I want that to
>> work
>> well so I can treat my Redmond allergy.
>>
>> I urge Smalltalkers to avoid #next and #next: like the plague, but
>> one
>> could always use my changes and ignore the replacements. A very
>> incomplete but gradually evolving change set is available on request.
>
> ok good to know.
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
