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<mailto: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<mailto: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/