Begin forwarded message:

From: "Bill Schwab" <[EMAIL PROTECTED]>
Date: June 1, 2008 9:34:45 PM CEDT
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: Discussion about Nile in Pharo

Stef,

I agree, though I would exchange the order. The RB fix of #next is simple, and I doubt there will ever be a completely painless time to do it. So I would do the rename, add the new/changed methods, and then convert to Nile, having updated its semantics prior to the conversion.

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

Stéphane Ducasse <[EMAIL PROTECTED]> 06/01/08 3:07 PM >>>
I think that you should

        - use the mailing-list
        - separate two things
                - the use of Nile as default
                - the fix of the behavior next:
        
Stef

On Jun 1, 2008, at 3:27 PM, Bill Schwab wrote:

Damien,

That is a great next step.  Dumb question: do I already have an
account by virtue of being on the list, or do I need to create one?

Your rewrite to cope with #on: is fascinating, but I continue to
wonder whether it is necessary.  In fact, I _think_ I would prefer
to rename the Nile classes (either up front or probably post-install
via the RB) to be generic.  While I too prefer idioms such as Array
writeStream and aCollection readStream, #on: is perfectly ok, though
clumsy.  What we should do depends on your goal, and of course on
what works best.

Changing to Nile via #readStream and #writeStream has its
advantages, but the rewrite has made me greedy :)  I am thinking of
something like the following:

(1) prepare the image by renaming methods (#next -> #nextOrNil:,
#next -> #nextAvailable:) to reflect current silently-truncating
semantics

(2) add the silent truncating methods to Nile; add #on: methods to
Nile, including comments referencing the shortcut methods

(3) change Nile's #next, #next: to raise errors; noting that after
(1), the image will call the truncating methods, and only new code
will see the errors

(4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or
perhaps better yet just ask the RB to rename the Nile classes, so
that one codes in terms of ReadStream, WriteStream, catches
EndOfStream. We can provide a defined set of RB steps that anyone
can use in a throw-away image to prepare code that we did not fix
for them; it should basically be step (1).

Comments?  If you at all agree, feel free to edit and put it on the
Wiki while I figure out how to access it.

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

"Damien Cassou" <[EMAIL PROTECTED]> 06/01/08 6:30 AM >>>
Hi Bill,

I writing a wiki page where I explain what we can do to slowly
install Nile:
https://gforge.inria.fr/plugins/wiki/index.php?refs=NileInstallation&id=1299&type=g

You can help me with the redaction.

--
Damien Cassou
Peter von der Ahé: «I'm beginning to see why Gilad wished us good
luck». (http://blogs.sun.com/ahe/entry/override_snafu)







_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to