siguctua at gmail.com
Thu Sep 3 20:30:42 EDT 2009
2009/9/3 Michael van der Gulik <mikevdg at gmail.com>:
> Argh. Please reply below other people's emails.
>> From: pharo-project-bounces at lists.gforge.inria.fr
>> [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Michael
>> van der Gulik
>> Sent: Thursday, September 03, 2009 5:54 PM
>> To: Pharo-project at lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] [ANN]
>> 2009/9/4 Miguel Enrique Cobá Martinez <miguel.coba at 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 at 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.
>> 2009/9/4 Schwab,Wilhelm K <bschwab at anest.ufl.edu>
>> 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
> Excuse the funny formatting. GMail sometimes doesn't cooperate. Also, this
> is getting a bit off topic on the Pharo list.
> No, it's not really to do with security. It's to do with this package system
> I invented.
> Basically, I want to reduce package dependencies. Putting >>readStream in
> kernel classes would make a package dependency between the Collection
> package and the Stream package. If the Collections package was loaded into
> SecureSqueak, the package architecture would be forced to load the Stream
> package as well even if it isn't used. If your own package depended on both
> Collection and a different Streams package, anybody who loaded your code
> would need to load two Streams packages.
> There's no reason that >>readStream couldn't be included in a Collections
> package, provided that it's not in the Collections package provided with the
> SecureSqueak Kernel. I want the Kernel package to have as few dependencies
> as possible. Packages are read-only in SecureSqueak and the Kernel package
> contains special objects, meaning that Kernel and its dependencies can not
> be upgraded without distributing a new image. Collections would be a
> non-upgradable dependency of Kernel, so I'd be trying hard to not also make
> Streams also a non-upgradable dependency.
Interesting dilemma. Right thing, that the package who responsible for
should be the one, who defines any streams of sort.
So, then collection could delegate to specific class the
responsibility for returning a stream.
Following the same logic, an Object class should not contain things
if we imagine things w/o collections, and then load a Collections
package, it should provide this method
by extending existing behavior.
But the problem is, that you need to extend an existing behavior, and
once you'll allow that, you are not in secure shell anymore.
I think there is solution. By example:
The Collection class , in Collection class could define a class var,
and then a simple method which allows to assign object to it.
And then, #readStream could be implemented as:
^ ReadStreamDelegate on: self
just don't say that classvars is read-only as well :)
You still have to make something non-readonly. So, if classvar is
readonly, then i could use one of a slots of an object held in
classvar to keep value there :)
> More info:
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev