2009/9/4 Peter Hugosson-Miller
<oldmanlink@gmail.com>
Michael,
Assuming you're referring to me. There're lots of Michaels around.
�
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.
Unless there's more magic here than I understand, Monticello also does this.
I'm *really* new to PharO and Squeak, Monticello and lots of other things, so I don't feel qualified to say one way or the other.
�
My package system can't do that. I can't work out a way to modify existing classes that won't cause complete chaos. SecureSqueak is designed to run completely untrusted code loaded from the Internet; allowing loaded code to override methods in other packages allows for too much bad stuff to happen.
It isn't a question of overriding specifically, but of adding methods to classes (which may then of course override methods in their superclasses). But since I don't know enough about SecureSqueak either, I don't really understand what your packaging system is intending to do either.
But now I'm afraid I've really dragged the discussion off-topic, for which I apologise :-)
�
If you can think of a way to do that securely, I'm all ears.
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project