Re: [Pharo-dev] About file printOn: method
+1 > Sent: Saturday, September 03, 2016 at 10:39 AM > From: stepharo > To: "Pharo Development List" > Subject: [Pharo-dev] About file printOn: method > > Hi > > > I will implement the following because this is too annoying. > > currently > > 'tmp/foo.txt' asFileReference > > > File @ tmp/foo.txt > > and it would be much much better to get back > 'tmp/foo.txt' asFileReference > > So that we can get > { 'tmp/foo.txt' asFileReference } > > { 'tmp/foo.txt' asFileReference } > > and not > "an Array(File @ tmp/foo.txt)" > > > In addition we should turn the current printOn: method into a > displayString method so that > a list of fileReference can be well display with File @ tmp/foo.txt for > example > > > https://pharo.fogbugz.com/f/cases/18956 > > >
Re: [Pharo-dev] About file printOn: method
It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo To: "Pharo Development List" Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference } and not "an Array(File @ tmp/foo.txt)" In addition we should turn the current printOn: method into a displayString method so that a list of fileReference can be well display with File @ tmp/foo.txt for example https://pharo.fogbugz.com/f/cases/18956
Re: [Pharo-dev] About file printOn: method
I'm a bit biased on this. IMHO this simplification in the #printString (which I quite like BTW!) is only applicable to Files in DiskFileSystem. If you have a FileReference on a non disk filesystem (e.g. fr1 := FileSystem memory root / 'folder' / 'test.txt'. "memory:///folder/test.txt" on use this simplified #printString you'll end up with '/folder/test.txt' asFileReference. This might be confusing as this does not mention the filesystem. So you might end up creating a new instance via fr2 := '/folder/test.txt' asFileReference. which is not equal to the original fileRef: fr1 = fr2 "false" As I do like the #printString simplification ... why not simply adopt a URI style scheme for FileReferences. This would allow encoding the filesystem type (e.g. file://, memory://, zip://, s3://) including parameters like host if needed and of course the path. CU, Udo On 04/09/16 09:47, stepharo wrote: It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo To: "Pharo Development List" Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference } and not "an Array(File @ tmp/foo.txt)" In addition we should turn the current printOn: method into a displayString method so that a list of fileReference can be well display with File @ tmp/foo.txt for example https://pharo.fogbugz.com/f/cases/18956
Re: [Pharo-dev] About file printOn: method
Hi Udo Thanks for the suggestion. It means that the printOn: should really involve the FieSystem and this is probably right. Now the point of the printOn: vs the displayString is that we can get back an object and right now we get a string :) Your URI suggestion should be applied to the displayString or the asFileReference should understand it. I added your feedback to the entry. Stef Le 9/9/16 à 20:19, Udo Schneider a écrit : I'm a bit biased on this. IMHO this simplification in the #printString (which I quite like BTW!) is only applicable to Files in DiskFileSystem. If you have a FileReference on a non disk filesystem (e.g. fr1 := FileSystem memory root / 'folder' / 'test.txt'. "memory:///folder/test.txt" on use this simplified #printString you'll end up with '/folder/test.txt' asFileReference. This might be confusing as this does not mention the filesystem. So you might end up creating a new instance via fr2 := '/folder/test.txt' asFileReference. which is not equal to the original fileRef: fr1 = fr2 "false" As I do like the #printString simplification ... why not simply adopt a URI style scheme for FileReferences. This would allow encoding the filesystem type (e.g. file://, memory://, zip://, s3://) including parameters like host if needed and of course the path. CU, Udo On 04/09/16 09:47, stepharo wrote: It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo To: "Pharo Development List" Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference } and not "an Array(File @ tmp/foo.txt)" In addition we should turn the current printOn: method into a displayString method so that a list of fileReference can be well display with File @ tmp/foo.txt for example https://pharo.fogbugz.com/f/cases/18956
Re: [Pharo-dev] About file printOn: method
Hi Stef, once upon in time :-) I picked up the notion that #printString "should" return a string which (when executed) results in the printed object. Whereras #displayString is "nicer" for the user. Not quite sure if this still applies though. But in this regard what about something like fr1 := FileSystem disk root / 'folder' / 'file.txt'. fr2 := FileSystem memory root / 'folder' / 'file.txt'. fr1 printString. "FileSystem // 'file:///folder/file.txt'" fr2 printString. "FileSystem // 'memory:///folder/file.txt'" fr1 displayString. "'file:///folder/file.txt'" fr2 displayString. "'memory:///folder/file.txt'" For FileReferences which use a FileSystem with a configured Store those settings could be added to the URL as host/query. E.g. for a WebDav FileReference: #printString "FileSystem // 'webdav://uid:pwd@host/folder/file.txt&usePatch=false'" #displayString "'webdav://uid:pwd@host/folder/file.txt'" CU, Udo On 09/09/16 20:34, stepharo wrote: Hi Udo Thanks for the suggestion. It means that the printOn: should really involve the FieSystem and this is probably right. Now the point of the printOn: vs the displayString is that we can get back an object and right now we get a string :) Your URI suggestion should be applied to the displayString or the asFileReference should understand it. I added your feedback to the entry. Stef Le 9/9/16 à 20:19, Udo Schneider a écrit : I'm a bit biased on this. IMHO this simplification in the #printString (which I quite like BTW!) is only applicable to Files in DiskFileSystem. If you have a FileReference on a non disk filesystem (e.g. fr1 := FileSystem memory root / 'folder' / 'test.txt'. "memory:///folder/test.txt" on use this simplified #printString you'll end up with '/folder/test.txt' asFileReference. This might be confusing as this does not mention the filesystem. So you might end up creating a new instance via fr2 := '/folder/test.txt' asFileReference. which is not equal to the original fileRef: fr1 = fr2 "false" As I do like the #printString simplification ... why not simply adopt a URI style scheme for FileReferences. This would allow encoding the filesystem type (e.g. file://, memory://, zip://, s3://) including parameters like host if needed and of course the path. CU, Udo On 04/09/16 09:47, stepharo wrote: It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo To: "Pharo Development List" Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference } and not "an Array(File @ tmp/foo.txt)" In addition we should turn the current printOn: method into a displayString method so that a list of fileReference can be well display with File @ tmp/foo.txt for example https://pharo.fogbugz.com/f/cases/18956
Re: [Pharo-dev] About file printOn: method
Le 9/9/16 à 20:57, Udo Schneider a écrit : Hi Stef, once upon in time :-) I picked up the notion that #printString "should" return a string which (when executed) results in the printed object. Yes we agree on this one. Now do you understand what are self evaluating objects? The idea there is that {10@20 . 33@44} printString returns {10@20 . 33@44} and not just anOrderedCollection (10 #@ 20 .) So this is what I was trying to get done. I do not know if what you propose (which can be better than what I was planning) requires to change fileSystem, my goal was not to change for now but just make sure that I can get cheaply file to print themselves into kind of objects I can manipulate again. Now if what you propose is better, then first we should introduce a logic to handle :file :memory And I'm not against so plese push it but this is outside of my little goal for now. Whereras #displayString is "nicer" for the user. Not quite sure if this still applies though. But in this regard what about something like fr1 := FileSystem disk root / 'folder' / 'file.txt'. fr2 := FileSystem memory root / 'folder' / 'file.txt'. fr1 printString. "FileSystem // 'file:///folder/file.txt'" fr2 printString. "FileSystem // 'memory:///folder/file.txt'" fr1 displayString. "'file:///folder/file.txt'" fr2 displayString. "'memory:///folder/file.txt'" For FileReferences which use a FileSystem with a configured Store those settings could be added to the URL as host/query. E.g. for a WebDav FileReference: #printString "FileSystem // 'webdav://uid:pwd@host/folder/file.txt&usePatch=false'" #displayString "'webdav://uid:pwd@host/folder/file.txt'" would be nice. Push this idea. Once the community agrees then we can easily extend the printOn: behavior. Did you watch the excellent talk of marcus at ESUG? Because I think incrementally CU, Udo On 09/09/16 20:34, stepharo wrote: Hi Udo Thanks for the suggestion. It means that the printOn: should really involve the FieSystem and this is probably right. Now the point of the printOn: vs the displayString is that we can get back an object and right now we get a string :) Your URI suggestion should be applied to the displayString or the asFileReference should understand it. I added your feedback to the entry. Stef Le 9/9/16 à 20:19, Udo Schneider a écrit : I'm a bit biased on this. IMHO this simplification in the #printString (which I quite like BTW!) is only applicable to Files in DiskFileSystem. If you have a FileReference on a non disk filesystem (e.g. fr1 := FileSystem memory root / 'folder' / 'test.txt'. "memory:///folder/test.txt" on use this simplified #printString you'll end up with '/folder/test.txt' asFileReference. This might be confusing as this does not mention the filesystem. So you might end up creating a new instance via fr2 := '/folder/test.txt' asFileReference. which is not equal to the original fileRef: fr1 = fr2 "false" As I do like the #printString simplification ... why not simply adopt a URI style scheme for FileReferences. This would allow encoding the filesystem type (e.g. file://, memory://, zip://, s3://) including parameters like host if needed and of course the path. CU, Udo On 04/09/16 09:47, stepharo wrote: It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo To: "Pharo Development List" Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference } and not "an Array(File @ tmp/foo.txt)" In addition we should turn the current printOn: method into a displayString method so that a list of fileReference can be well display with File @ tmp/foo.txt for example https://pharo.fogbugz.com/f/cases/18956
Re: [Pharo-dev] About file printOn: method
On 10/09/16 10:52, stepharo wrote: So this is what I was trying to get done. I do not know if what you propose (which can be better than what I was planning) requires to change fileSystem, my goal was not to change for now but just make sure that I can get cheaply file to print themselves into kind of objects I can manipulate again. Now if what you propose is better, then first we should introduce a logic to handle :file :memory And I'm not against so plese push it but this is outside of my little goal for now. You're right. Your solution is much simpler - therefore I'd go with your solution for now. would be nice. Push this idea. Once the community agrees then we can easily extend the printOn: behavior. I'll try to work through the FS code and see if I can get the stuff I'm thinking about implemented. Did you watch the excellent talk of marcus at ESUG? Because I think incrementally One of the first videos/slidedecks I watched - the title made me curious. My key take-away is that it's better to implement the cheap/simple/non-perfect enhancement now than never (too late) the perfect one.
Re: [Pharo-dev] About file printOn: method
o this is what I was trying to get done. I do not know if what you propose (which can be better than what I was planning) requires to change fileSystem, my goal was not to change for now but just make sure that I can get cheaply file to print themselves into kind of objects I can manipulate again. Now if what you propose is better, then first we should introduce a logic to handle :file :memory And I'm not against so plese push it but this is outside of my little goal for now. You're right. Your solution is much simpler - therefore I'd go with your solution for now. would be nice. Push this idea. Once the community agrees then we can easily extend the printOn: behavior. I'll try to work through the FS code and see if I can get the stuff I'm thinking about implemented. Please :) I like the idea of URI for everything Did you watch the excellent talk of marcus at ESUG? Because I think incrementally One of the first videos/slidedecks I watched - the title made me curious. My key take-away is that it's better to implement the cheap/simple/non-perfect enhancement now than never (too late) the perfect one. :)
Re: [Pharo-dev] About file printOn: method
On Sun, Sep 11, 2016 at 4:37 AM, stepharo wrote: > o this is what I was trying to get done. > >> I do not know if what you propose (which can be better than what I was >>> planning) requires to change fileSystem, my goal was not to change for >>> now but just make sure that I can get cheaply file to print themselves >>> into kind of objects I can manipulate again. >>> >>> Now if what you propose is better, then first we should introduce a >>> logic to handle :file :memory >>> >>> And I'm not against so plese push it but this is outside of my little >>> goal for now. >>> >> You're right. Your solution is much simpler - therefore I'd go with your >> solution for now. >> >> would be nice. Push this idea. Once the community agrees then we can >>> easily extend the printOn: behavior. >>> >> I'll try to work through the FS code and see if I can get the stuff I'm >> thinking about implemented. >> > Please :) > I like the idea of URI for everything Do you mean a URI represented as a String or as a URI object? I expect the former since ultimately pintOn: is called by printString, but I wanted to be clear? cheers -ben > > >> Did you watch the excellent talk of marcus at ESUG? >>> Because I think incrementally >>> >> One of the first videos/slidedecks I watched - the title made me curious. >> My key take-away is that it's better to implement the >> cheap/simple/non-perfect enhancement now than never (too late) the perfect >> one. >> > > :) > > > > >
Re: [Pharo-dev] About file printOn: method
> On Sep 10, 2016, at 12:28 PM, Udo Schneider > wrote: > >> On 10/09/16 10:52, stepharo wrote: >> So this is what I was trying to get done. >> I do not know if what you propose (which can be better than what I was >> planning) requires to change fileSystem, my goal was not to change for >> now but just make sure that I can get cheaply file to print themselves >> into kind of objects I can manipulate again. >> >> Now if what you propose is better, then first we should introduce a >> logic to handle :file :memory >> >> And I'm not against so plese push it but this is outside of my little >> goal for now. > You're right. Your solution is much simpler - therefore I'd go with your > solution for now. > >> would be nice. Push this idea. Once the community agrees then we can >> easily extend the printOn: behavior. > I'll try to work through the FS code and see if I can get the stuff I'm > thinking about implemented. > >> Did you watch the excellent talk of marcus at ESUG? >> Because I think incrementally > One of the first videos/slidedecks I watched - the title made me curious. My > key take-away is that it's better to implement the cheap/simple/non-perfect > enhancement now than never (too late) the perfect one. "Don't let the perfect be the enemy of the good."