Why `aFileReference asString = aFileReference fullName` is false?
A frequent thing to do is to work with files, so their paths. Take the image directory for example: `FileLocator imageDirectory resolve asString` 1) Whatâs the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers? 2) Whatâs the practical use of the current answer of `aFileReference asString`?
The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
On 09 Mar 2015, at 16:06, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
A frequent thing to do is to work with files, so their paths.
Take the image directory for example:
`FileLocator imageDirectory resolve asString`
1) Whatâs the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
2) Whatâs the practical use of the current answer of `aFileReference asString`?
right, and what's the practical use of that? from mobile
On 09/03/2015, at 12:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
On 09 Mar 2015, at 16:06, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
A frequent thing to do is to work with files, so their paths.
Take the image directory for example:
`FileLocator imageDirectory resolve asString`
1) Whatâs the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
2) Whatâs the practical use of the current answer of `aFileReference asString`?
Yo should use #pathString to obtain the full path of the file reference. #asString isn't implemented in FileReference and it's inherited from Object, which delegates it to the default implementation of #printString, which isn't intented to be user friendly, and not for conversion. Regards! Esteban A. Maringolo 2015-03-09 22:35 GMT-03:00 Sebastian Sastre <sebastian@flowingconcept.com>:
right, and what's the practical use of that?
from mobile
On 09/03/2015, at 12:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
On 09 Mar 2015, at 16:06, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
A frequent thing to do is to work with files, so their paths.
Take the image directory for example:
`FileLocator imageDirectory resolve asString`
1) Whatâs the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
2) Whatâs the practical use of the current answer of `aFileReference asString`?
On Tue, Mar 10, 2015 at 9:52 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Yo should use #pathString to obtain the full path of the file reference.
#asString isn't implemented in FileReference and it's inherited from Object, which delegates it to the default implementation of #printString, which isn't intented to be user friendly, and not for conversion.
Regards! Esteban A. Maringolo
Thanks for the explanation Esteban. Now the followup question is whether its natural to expect something better from #asString, and other people will fall into the same trap? cheers -ben
2015-03-09 22:35 GMT-03:00 Sebastian Sastre <sebastian@flowingconcept.com
: right, and what's the practical use of that?
from mobile
On 09/03/2015, at 12:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The thing before the @ indicates the kind of file system you are on (there are not just disk based files, but virtual in-memory ones, or in-zip ones).
On 09 Mar 2015, at 16:06, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
A frequent thing to do is to work with files, so their paths.
Take the image directory for example:
`FileLocator imageDirectory resolve asString`
1) Whatâs the reason to make `aFileReference asString` to be different to what `aFileReference fullName` answers?
2) Whatâs the practical use of the current answer of `aFileReference asString`?
Ben Coman wrote
Now the followup question is whether its natural to expect something better from #asString
I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending e.g. #displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation. I think that we could promote this to displayString now that it is in the Pharo image. Cheers, Doru On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Now the followup question is whether its natural to expect something better from #asString
I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending e.g. #displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
Well, not now. In Pharo 5 :) Doru On Tue, Mar 10, 2015 at 12:18 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation.
I think that we could promote this to displayString now that it is in the Pharo image.
Cheers, Doru
On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Now the followup question is whether its natural to expect something better from #asString
I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending e.g. #displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Please open a bug entry that we do not forget and yes we need displayString
Well, not now. In Pharo 5 :)
Doru
On Tue, Mar 10, 2015 at 12:18 PM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Indeed. In GT, we introduced gtDisplayString which is meant to be used as a default brief string representation.
I think that we could promote this to displayString now that it is in the Pharo image.
Cheers, Doru
On Tue, Mar 10, 2015 at 12:03 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Ben Coman wrote > Now the followup question is whether its natural to expect something > better from #asString
I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending e.g. #displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-aFileReference-asString-aFileReference-fullName-is... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
El mar 10, 2015 8:13 AM, "Sean P. DeNigris" <sean@clipperadams.com> escribió:
Ben Coman wrote
Now the followup question is whether its natural to expect something better from #asString
I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending
e.g.
#displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me.
I would remove #asString and use #displayString everywhere. But it should be implemented in Object, based on a #displayOn: method just like printString does. If a method starts with #as... I read "I will cast this object into something else". Which will be subject to taste. Regarding this particular case I would implement #asString as a delegation to the method that returns '/foo/bar/baz'. An URL's #asString would return 'file:///foo/bar/baz'. Regards!
Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem. The problem is that there is often more than one useful string representation. Like for the example at hand. (FileLocator desktop / 'foo.txt') resolve. Has the following #printString File @ /Users/sven/Desktop/foo.txt OK, both of the following make sense /Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt But what about native (OS platform) conventions ? I don't want to see Windows backslashes, but Windows user might disagree. There is not one good solution, hence you must use specific accessors/convertors.
On 10 Mar 2015, at 12:20, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
El mar 10, 2015 8:13 AM, "Sean P. DeNigris" <sean@clipperadams.com> escribió:
Ben Coman wrote
Now the followup question is whether its natural to expect something better from #asString
I feel like #asString is such a general question that no answer would be satisfying. What string representation should be returned? 'file://'? '/path/to'? And what to do with memory file systems? It's been mentioned a few times on the list that we should all be more disciplined in sending e.g. #displayString vs. #printString instead of #asString. The more I hear that argument, the more sense it makes to me.
I would remove #asString and use #displayString everywhere. But it should be implemented in Object, based on a #displayOn: method just like printString does.
If a method starts with #as... I read "I will cast this object into something else". Which will be subject to taste.
Regarding this particular case I would implement #asString as a delegation to the method that returns '/foo/bar/baz'. An URL's #asString would return 'file:///foo/bar/baz'.
Regards!
2015-03-10 8:43 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem.
The problem is that there is often more than one useful string representation.
That's why I said it is a matter of taste. In the end, not having a concrete #asString implementation might be a good choice. Esteban A. Maringolo
On Mar 10, 2015, at 8:43 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
OK, both of the following make sense
/Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt <file:///Users/sven/Desktop/foo.txt>
But what about native (OS platform) conventions ?
I don't want to see Windows backslashes, but Windows user might disagree.
There is not one good solution, hence you must use specific accessors/convertors.
The alternative to no one good solution is to find the sensible less worst solution. Do we have a way to strategise the answer of asString per supported platform in such a way that it will conform the string representation of the path to a file? Iâm still trying to understand the practical use of the current answer instead of strategize the answer per platform
the standard string representation of an abstract platform independent representation of a file should be that: abstract & platform independent (it would be terrible to mask that behind a platform dependent external representation) furthermore it makes sense that the print string gives an indication of what it actually is/models: hence it is useful to add the type reference (else totally different ones will look the same) there are other accessors that do what you want, why can't you use those ? most objects cannot come up with just one single canonical representation for example, according to universal standards, ZnUrl and ZnMimeType can do this, but these are exceptions
On 10 Mar 2015, at 16:47, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Mar 10, 2015, at 8:43 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
OK, both of the following make sense
/Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt
But what about native (OS platform) conventions ?
I don't want to see Windows backslashes, but Windows user might disagree.
There is not one good solution, hence you must use specific accessors/convertors.
The alternative to no one good solution is to find the sensible less worst solution.
Do we have a way to strategise the answer of asString per supported platform in such a way that it will conform the string representation of the path to a file?
Iâm still trying to understand the practical use of the current answer instead of strategize the answer per platform
On Mar 10, 2015, at 12:57 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
the standard string representation of an abstract platform independent representation of a file should be that: abstract & platform independent (it would be terrible to mask that behind a platform dependent external representation)
furthermore it makes sense that the print string gives an indication of what it actually is/models: hence it is useful to add the type reference (else totally different ones will look the same)
there are other accessors that do what you want, why can't you use those ?
most objects cannot come up with just one single canonical representation
for example, according to universal standards, ZnUrl and ZnMimeType can do this, but these are exceptions
Iâm already using alternatives to asString, Iâm not stuck, Iâm trying to understand why asString is not providing what I consider a practical answer to a universal need (string representation of a file reference). Why the strategy of asString would not have a fallback to a really abstract representation for an unknown platform and return the useful answer for when is familiarized to a particular OS? Aren't *nix platforms universal enough?
/Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt
But what about native (OS platform) conventions ?
I don't want to see Windows backslashes, but Windows user might disagree.
file:// is URI scheme and as per RFC ( http://tools.ietf.org/html/rfc1630 ) there is always forward slash; even on Windows. After all as we've found with git, using backslashes on Windows doesn't even work... so maybe use file:// as universal scheme?
On 10 Mar 2015, at 17:31, Peter Uhnák <i.uhnak@gmail.com> wrote:
/Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt
But what about native (OS platform) conventions ?
I don't want to see Windows backslashes, but Windows user might disagree.
file:// is URI scheme and as per RFC ( http://tools.ietf.org/html/rfc1630 ) there is always forward slash; even on Windows. After all as we've found with git, using backslashes on Windows doesn't even work... so maybe use file:// as universal scheme?
I don't agree, because *IT IS NOT A FILE URL*, *IT IS MORE* It is a thing that looks like an abstract file of something that looks like a file system, not necessarily a regular disk based one, this has to be reflected in its general print representation, else you are lying/confusing the user
participants (8)
-
Ben Coman -
Esteban A. Maringolo -
Peter Uhnák -
Sean P. DeNigris -
Sebastian Sastre -
stepharo -
Sven Van Caekenberghe -
Tudor Girba