About file printOn: method
Locked
 
|
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 |
|
|
+1
> Sent: Saturday, September 03, 2016 at 10:39 AM > From: stepharo <[hidden email]> > To: "Pharo Development List" <[hidden email]> > 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 > > > |
|
|
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 <[hidden email]> >> To: "Pharo Development List" <[hidden email]> >> 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 >> >> >> > |
|
|
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 <[hidden email]> >>> To: "Pharo Development List" >>> <[hidden email]> >>> 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 >>> >>> >>> >> > > > |
|
|
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 <[hidden email]> >>>> To: "Pharo Development List" >>>> <[hidden email]> >>>> 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 >>>> >>>> >>>> >>> >> >> >> > > > > |
|
|
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 <[hidden email]> >>>>> To: "Pharo Development List" >>>>> <[hidden email]> >>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> >> > > > |
|
|
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 <[hidden email]> >>>>>> To: "Pharo Development List" >>>>>> <[hidden email]> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > > |
|
|
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. 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. |
|
|
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. 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. :) |
|
|
On Sun, Sep 11, 2016 at 4:37 AM, stepharo <[hidden email]> wrote: o this is what I was trying to get done. 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
|
Re: About file printOn: method
|
|
In reply to this post by Udo Schneider
> On Sep 10, 2016, at 12:28 PM, Udo Schneider <[hidden email]> 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." |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |