Bill
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.
2009/9/4 Schwab,Wilhelm K
<bschwab@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 methods...
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.
More info:
http://gulik.pbwiki.com/Namespaceshttp://gulik.pbwiki.com/PackagesGulik.