About file printOn: method

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

About file printOn: method

stepharo
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


Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

monty-3
+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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

stepharo
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
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

Udo Schneider
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
>>>
>>>
>>>
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

stepharo
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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

Udo Schneider
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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

stepharo


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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

Udo Schneider
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.




Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

stepharo
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.

:)




Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

Ben Coman


On Sun, Sep 11, 2016 at 4:37 AM, stepharo <[hidden email]> 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.

:)





Reply | Threaded
Open this post in threaded view
|

Re: About file printOn: method

Eliot Miranda-2
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."