- Issue 1144: Many occurrences of "ReadStream on: aCollection" which can be replaced with "aCollection readStream"
the problem that not all classes define #readStream.. as far as i remember, i had some issues with it, and forced to use "ReadStream on:" instead 2009/9/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
- Issue 1144: Â Many occurrences of "ReadStream on: aCollection" which can be replaced with "aCollection readStream"
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Sig, One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case. It is easy to define #readStream where appropriate, and IMHO Pharo should do so. Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods. I submit that the problem is instead all of the external code that will still explicitly reference ReadStream. That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board. More challenging still are the inconsistencies in exhaustion behavior. Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal. I can also not afford to wait for the decision to be made and imlemented. For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code. If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages. FWIW, one of the first things I did was define #readStream on various collections and collection classes. Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, September 03, 2009 10:42 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] the problem that not all classes define #readStream.. as far as i remember, i had some issues with it, and forced to use "ReadStream on:" instead 2009/9/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
- Issue 1144: Â Many occurrences of "ReadStream on: aCollection" which can be replaced with "aCollection readStream"
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/9/3 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case. Â It is easy to define #readStream where appropriate, and IMHO Pharo should do so. Â Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods.
I understanding this, but at that moment i weren't sure if this is a missing method, or it is missing by intent. Also i had to make sure that my code works also for 3.10. So, for me it was an easiest thing to leave things as they are.
I submit that the problem is instead all of the external code that will still explicitly reference ReadStream. Â That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board.
Right: i'm trying to not use globals if its possible, except well known classes like Arrays, collections etc.
More challenging still are the inconsistencies in exhaustion behavior. Â Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal. Â I can also not afford to wait for the decision to be made and imlemented. Â For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code. Â If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages.
i missed this part of discussion, so i can't comment the above.
FWIW, one of the first things I did was define #readStream on various collections and collection classes. Â Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days.
The arguments like 'it is done like that somewhere' is a bad way to convince me (and i assume many others). I think you are already given enough arguments before and they already good enough to convince everyone (i hope), except me, because you don't need to convince me on that :)
Bill
-- Best regards, Igor Stasenko AKA sig.
Sig, I doubt you missed anything; I dragged EndOfStreamError into it because IMHO, that's where the real problems wait for us. If I had to make code work on 3.10, I would fill in missing pieces (in this case #readStream) there rather than hold back my Pharo code; in fact, that's more or less what I am doing with Pharo too. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, September 03, 2009 6:42 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 2009/9/3 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
One of the great things about Smalltalk is that we are seldom forced to do anything, and certainly not in this case. Â It is easy to define #readStream where appropriate, and IMHO Pharo should do so. Â Not only does it give cleaner code, it will help us insert Nile when the time comes, and we can simply add the missing methods.
I understanding this, but at that moment i weren't sure if this is a missing method, or it is missing by intent. Also i had to make sure that my code works also for 3.10. So, for me it was an easiest thing to leave things as they are.
I submit that the problem is instead all of the external code that will still explicitly reference ReadStream. Â That is not a reason to not make the change, and I am hoping that a little leadership by example will cause the right thing to happen across the board.
Right: i'm trying to not use globals if its possible, except well known classes like Arrays, collections etc.
More challenging still are the inconsistencies in exhaustion behavior. Â Referring to my proposal on the wiki, I stand ready to help if we want to enforce EndOfStreamError on any "unauthorized" exhaustion, but I have my doubts that we will do so; Cincom considered and declined the proposal. Â I can also not afford to wait for the decision to be made and imlemented. Â For now, I am gradually moving my code toward #nextOne, #nextMany:, etc., which again can be done simply by adding new code. Â If Pharo adopts EndOfStreamError, I can easily change from my new protocol to the more generic messages.
i missed this part of discussion, so i can't comment the above.
FWIW, one of the first things I did was define #readStream on various collections and collection classes. Â Dolphin (sorry to keep beating the drum, but it sets a wonderful example!) has had #readStream "everywhere" for a long time if not from its earliest days.
The arguments like 'it is done like that somewhere' is a bad way to convince me (and i assume many others). I think you are already given enough arguments before and they already good enough to convince everyone (i hope), except me, because you don't need to convince me on that :)
Bill
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Gulik. -- http://gulik.pbwiki.com/
Then #readStreamXYZ would do the job. Depending on how you write the methods, both you and the collection have a say, or you can also have complete control. ________________________________ 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 4:33 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 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. Gulik. -- http://gulik.pbwiki.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?
Gulik.
-- http://gulik.pbwiki.com/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
Sure. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martinez Sent: Thursday, September 03, 2009 4:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 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?
Gulik.
-- http://gulik.pbwiki.com/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Gulik. -- http://gulik.pbwiki.com/
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/
Argh. Please reply below other people's emails. 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>
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/Namespaces http://gulik.pbwiki.com/Packages Gulik. -- http://gulik.pbwiki.com/
2009/9/4 Michael van der Gulik <mikevdg@gmail.com>
Argh. Please reply below other people's emails.
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>
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/Namespaces http://gulik.pbwiki.com/Packages
Gulik.
_______________________________________________ Pharo-project mailing list Pharo-project@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
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. 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. If you can think of a way to do that securely, I'm all ears. Gulik. -- http://gulik.pbwiki.com/
2009/9/4 Michael van der Gulik <mikevdg@gmail.com> Yes, my answer was meant for you.
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.
Gulik.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Cheers, Peter
Peter you should have a look at Squeak by example and soon pharo by example in short if you had a category with *MyPackage in a class of another package then your package MyPackage will contain the extensions. You can see the extension by clicking on the Monticello browser and clicking browse. In fact this is a good practice to check the extensions of a package before publishing it. I can show you during the break :) Stef
I also prefer ReadStream on: since it is explicit about the stream you want rather than expecting the collection to know and have the protocol. I don't really see the need to rewrite the whole image. Cheers mike On Friday, September 4, 2009, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Peter you should have a look at Squeak by example and soon pharo by example
in short if you had a category with *MyPackage in a class of another package then your package MyPackage will contain the extensions.
You can see the extension by clicking on the Monticello browser and clicking browse.
In fact this is a good practice to check the extensions of a package before publishing it.
I can show you during the break :)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes but if we want to make sure that we could plug easily a new stream library we should either use virtual classes (quite difficult and major changes at language level) or readStream So readStream gives us a nice solution. Stef
I also prefer ReadStream on: since it is explicit about the stream you want rather than expecting the collection to know and have the protocol. I don't really see the need to rewrite the whole image.
Cheers mike
On Friday, September 4, 2009, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Peter you should have a look at Squeak by example and soon pharo by example
in short if you had a category with *MyPackage in a class of another package then your package MyPackage will contain the extensions.
You can see the extension by clicking on the Monticello browser and clicking browse.
In fact this is a good practice to check the extensions of a package before publishing it.
I can show you during the break :)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, IIRC, Object Arts started promoting name spaces at one point, and (my best guess) ended up finding a very interesting solution using messages. I believe they call the result an environment, and by asking something for its environment that in turn understands messages to access classes one can do things like Smalltalk stef browser show. Smalltalk bill browser show. Where #stef and #bill provide our respective environments, and #browser answers a class. I'm not sure if that is at all relevant - free advice is often worth what we pay for it :) Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Friday, September 04, 2009 3:05 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Yes but if we want to make sure that we could plug easily a new stream library we should either use virtual classes (quite difficult and major changes at language level) or readStream So readStream gives us a nice solution. Stef
I also prefer ReadStream on: since it is explicit about the stream you want rather than expecting the collection to know and have the protocol. I don't really see the need to rewrite the whole image.
Cheers mike
On Friday, September 4, 2009, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Peter you should have a look at Squeak by example and soon pharo by example
in short if you had a category with *MyPackage in a class of another package then your package MyPackage will contain the extensions.
You can see the extension by clicking on the Monticello browser and clicking browse.
In fact this is a good practice to check the extensions of a package before publishing it.
I can show you during the break :)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I have used #readStream and variants for a long time; I think you will like it if you try it. The code is cleaner, avoids a set of parentheses at each call, and one can always create variants on it when more control is necessary. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts Sent: Friday, September 04, 2009 2:45 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] I also prefer ReadStream on: since it is explicit about the stream you want rather than expecting the collection to know and have the protocol. I don't really see the need to rewrite the whole image. Cheers mike On Friday, September 4, 2009, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Peter you should have a look at Squeak by example and soon pharo by example
in short if you had a category with *MyPackage in a class of another package then your package MyPackage will contain the extensions.
You can see the extension by clicking on the Monticello browser and clicking browse.
In fact this is a good practice to check the extensions of a package before publishing it.
I can show you during the break :)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Sep 4, 2009 at 9:38 AM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Peter you should have a look at Squeak by example and soon pharo by example
in short if you had a category with *MyPackage in a class of another package then your package MyPackage will contain the extensions.
You can see the extension by clicking on the Monticello browser and clicking browse.
In fact this is a good practice to check the extensions of a package before publishing it.
I can show you during the break :)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hej Stef, I was up quite late last night (=this morning) preparing that huge slice for the WriteStream on: issue, so I overslept this morning, and I have to be at the train station by 12:00 today, so I think I'll stay in my hôtel until then. But if you can point me to a concrete example, I'm sure I'll understand it when I see it. -- Cheers, Peter
ok look at the Regex package. Click browse and you will that regex has class extension in string and character. Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hej Stef,
I was up quite late last night (=this morning) preparing that huge slice for the WriteStream on: issue, so I overslept this morning, and I have to be at the train station by 12:00 today, so I think I'll stay in my hôtel until then.
But if you can point me to a concrete example, I'm sure I'll understand it when I see it.
-- Cheers, Peter _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok. Please note that your package system and limits it imposes might affect "market share". Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Peter Hugosson-Miller Sent: Thursday, September 03, 2009 7:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] 2009/9/4 Michael van der Gulik <mikevdg@gmail.com<mailto:mikevdg@gmail.com>> Argh. Please reply below other people's emails. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto: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<mailto: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. 2009/9/4 Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto: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/Namespaces http://gulik.pbwiki.com/Packages Gulik. -- http://gulik.pbwiki.com/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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
2009/9/3 Michael van der Gulik <mikevdg@gmail.com>:
Argh. Please reply below other people's emails.
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>
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.
Interesting dilemma. Right thing, that the package who responsible for implementing #readStream 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 like #isCollection, 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, like ReadStreamDelegate and then a simple method which allows to assign object to it. And then, #readStream could be implemented as: readStream ^ 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: http://gulik.pbwiki.com/Namespaces http://gulik.pbwiki.com/Packages
Gulik.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I'd love to - how do you get LookOut! 2003 to comment text? It amazes me that people who write software for a living don't grok the need for that ability, but I've been saddled with this piece of junk, and the piece of junk before it, that appear to be unable to do it. ________________________________ 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 6:51 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] Argh. Please reply below other people's emails. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto: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<mailto: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. 2009/9/4 Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto: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/Namespaces http://gulik.pbwiki.com/Packages Gulik. -- http://gulik.pbwiki.com/
Yes me too but we should avoid hardcoding class references that core everywhere. Stef On Sep 3, 2009, at 11:33 PM, Michael van der Gulik wrote: > > > 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. > > Gulik. > > -- > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Igor Stasenko -
Michael Roberts -
Michael van der Gulik -
Miguel Enrique Cobá Martinez -
Peter Hugosson-Miller -
Schwab,Wilhelm K -
Stéphane Ducasse