[Pharo-project] [ANN]

Schwab,Wilhelm K bschwab at anest.ufl.edu
Thu Sep 3 19:49:41 EDT 2009


I doubt you missed anything; I dragged EndOfStreamError into it because IMHO, that's where the real problems wait for us.  If I had to make code work on 3.10, I would fill in missing pieces (in this case #readStream) there rather than hold back my Pharo code; in fact, that's more or less what I am doing with Pharo too.


-----Original Message-----
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Thursday, September 03, 2009 6:42 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [ANN]

2009/9/3 Schwab,Wilhelm K <bschwab at anest.ufl.edu>:
> Sig,
> One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case.  It is easy to define #readStream where appropriate, and IMHO Pharo should do so.  Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods.
I understanding this, but at that moment i weren't sure if this is a missing method, or it is missing by intent. Also i had to make sure that my code works also for 3.10.  So, for me it was an easiest thing to leave things as they are.

> I submit that the problem is instead all of the external code that will still explicitly reference ReadStream.  That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board.
Right: i'm trying to not use globals if its possible, except well known classes like Arrays, collections etc.

> More challenging still are the inconsistencies in exhaustion behavior.  Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal.  I can also not afford to wait for the decision to be made and imlemented.  For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code.  If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages.

i missed this part of discussion, so i can't comment the above.

> FWIW, one of the first things I did was define #readStream on various collections and collection classes.  Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days.

The arguments like 'it is done like that somewhere' is a bad way to convince me (and i assume many others).
I think you are already given enough arguments before and they already good enough to convince everyone (i hope), except me, because you don't need to convince me on that :)

> Bill

Best regards,
Igor Stasenko AKA sig.

Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr

More information about the Pharo-dev mailing list