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 <steph...@free.fr>
To: "Pharo Development List"
<pharo-dev@lists.pharo.org>
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 via email to