Ok, I'm interested :)  Is there a security argument?  Off the top, it does not sound like something I would want to use.  If you can make a case that #readStream is dangerous, I'm all ears.  If it is simply that it closes off modifications to the base classes, it is probably too restictive for my tastes.  Locking it down **after** I add the missing methods and deploy on  a server, that's another matter.  But then, there would be #readStream methods...
 
Bill
 

From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik
Sent: Thursday, September 03, 2009 5:54 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] [ANN]



2009/9/4 Miguel Enrique Cob� Martinez <miguel.coba@gmail.com>
El vie, 04-09-2009 a las 09:33 +1200, Michael van der Gulik escribi�:
>
>
> On Fri, Sep 4, 2009 at 3:21 AM, St�phane Ducasse
> <stephane.ducasse@inria.fr> wrote:
>         - Issue 1144:   Many occurrences of "ReadStream on:
>         aCollection" which
>         can be replaced with "aCollection readStream"
>
>
> For what it's worth, I prefer the style of "ReadStream on: xxx". I
> prefer to choose the stream class rather than let the collection
> choose it for me.

But don't you always have the option to call ReadStream on: object,
even though object class has a readStream method?


In Pharo, sure.

However, in SecureSqueak, there won't be >>readStream methods. I'll spare the details because I hate multi-page emails. Ask me if you're interested.

Gulik.

--
http://gulik.pbwiki.com/