Begin forwarded message:
From: "Bill Schwab" <[EMAIL PROTECTED]>
Date: June 1, 2008 4:32:46 PM CEDT
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: Discussion about Nile in Pharo
Damien,
A partial reply. Interesting point about the various collection
classes. Perhaps we can double-dispatch to make the creation work,
something like
ReadStream on:aCollection
^aCollection readStream.
ReadStream and friends would exist, but concrete classes would be
instantiated. Could that work? It would be along the lines of
Squeak's file directories, where the programmer can think in
abstractions and the code does the right thing (and instantiates the
correct classes) for the platform.
As far as #next, my proposal is to avoid the error altogether by
transforming (RB) old code so that it uses #nextOrNil and will work
as before, but without abusing the contentious selector.
Untransformed old code would likely break, but there would be a
procedure for using a throw-away Squeak image to fix it for
inclusion in Pharo, and we would have already done transformed code
considered to be part of Pharo. My instinct tells me to get it done
up front, for fear that the backward-compatibility arguments would
prevent doing it in the future. I am not usually a disk-pack
arsonist, but in this case, the sooner the better IMHO. Again, a
few messages to the RB, and nothing changes except we rename the
abused selector. Everything continues to work; new code can work as
it should.
I can check with Dolphin, but I do not believe #peek* are affected.
It could get interesting for sockets where new elements could be in
transit, but the general feel of peek is to look and either move
past the element or leave the position unchanged; the latter would
probably be what happens. I will ponder and look at the other
dialects.
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 9:47 AM >>>
On Sun, Jun 1, 2008 at 3:27 PM, Bill Schwab <[EMAIL PROTECTED]>
wrote:
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?
You have to create an account I think. Then, you has to ask the pharo
project to join. We will receive a mail and will be able to accept
your request (or refuse, we will see :-D).
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.
I do not agree for the following reasons:
- in Nile, there is just one class which is the equivalent of
ReadStream, WriteStream and ReadWriteStream. It is named
NSCollectionStream. There is no one-to-one relation.
- in Nile, there are specific classes to handle strings and arrays,
NSStringStream and NSArrayStream.How do you change the existing source
code to use the right stream class depending on the collection class?
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
- I'm not sure we should do this change now. I would prefer waiting
that Nile is the default Stream implementation. That way, we avoid
changing the Squeak Stream library. Moreover, I think people need more
time to think about throwing errors with #next. They need to see how
that change will affect their code in practice. Moreover, this change
might introduce a lot of new methods like peekIfAvailable and others.
(2) add the silent truncating methods to Nile;
add #on: methods to Nile, including comments referencing the
shortcut methods
#on: is already in Nile and it is the only way to create a new
collection stream.
(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.
--
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
