[Pharo-project] [ANN]

Schwab,Wilhelm K bschwab at anest.ufl.edu
Thu Sep 3 20:37:47 EDT 2009


Ok.  Please note that your package system and limits it imposes might affect "market share".

Bill




________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller
Sent: Thursday, September 03, 2009 7:00 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [ANN]

2009/9/4 Michael van der Gulik <mikevdg at gmail.com<mailto:mikevdg at gmail.com>>
Argh. Please reply below other people's emails.


Bill



________________________________
From: pharo-project-bounces at lists.gforge.inria.fr<mailto:pharo-project-bounces at lists.gforge.inria.fr> [mailto: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<mailto:Pharo-project at lists.gforge.inria.fr>
Subject: Re: [Pharo-project] [ANN]



2009/9/4 Miguel Enrique Cobá Martinez <miguel.coba at gmail.com<mailto: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<mailto: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<mailto: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 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/Namespaces
http://gulik.pbwiki.com/Packages

Gulik.

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

_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

This is one of those cases that really makes me miss ENVY, and its Class extentions. Under that system you would avoid the problem completely, by extending the Collection class in the Stream package and adding the methods that depend on Streams in that package.

I guess everyone knows what ENVY Class extensions are, but just in case someone doesn't, they are basically collections of methods to be added to a Class already in the image (i.e. not subclasses), when the extension is loaded.

--
Cheers,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090903/bfd8cae4/attachment-0001.html>


More information about the Pharo-dev mailing list