inconsistent FileLocator behavior
Hi, is there a reason why FileLocator behaves like this? FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\) Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous. What is the use case that you don't want to resolve it yet? Thanks, Peter
2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak@gmail.com>:
Hi,
is there a reason why FileLocator behaves like this?
FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\)
Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
What is the use case that you don't want to resolve it yet?
Thanks, Peter
From the FileLocator class comment: "I am a late-bound reference. "
2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak@gmail.com>:
Hi,
is there a reason why FileLocator behaves like this?
FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\)
Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
In what situation do you need to call #asFileReference ? because I thought a FileLocator should behave like a FileReference (implementingthe same api).
What is the use case that you don't want to resolve it yet?
Thanks, Peter
It is polymorphic, but the usability suffers (at least for me). Imagine that I want to pick a path to specific file - for example something in Downloads folder. If I don't have the full path at my hand, I open the playground and type FileLocator home asFileReference -> I see all the contents, then I can add `/ 'Downloads' -> again, I see all the contents, etc. If I don't resolve it immediately, I won't see neither the final file, nor will I see if I made a mistake along the way. Also how is `FileLocator home` any more or less specific than `FileLocator D`? Neither is guaranteed to be the same (or even exist) for all users. Peter On Wed, Dec 14, 2016 at 10:25:08AM +0100, Nicolai Hess wrote:
2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak@gmail.com>:
Hi,
is there a reason why FileLocator behaves like this?
FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\)
Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
In what situation do you need to call #asFileReference ? because I thought a FileLocator should behave like a FileReference (implementingthe same api).
What is the use case that you don't want to resolve it yet?
Thanks, Peter
On Wed, Dec 14, 2016 at 6:18 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
It is polymorphic, but the usability suffers (at least for me).
Imagine that I want to pick a path to specific file - for example something in Downloads folder.
If I don't have the full path at my hand, I open the playground and type
FileLocator home asFileReference -> I see all the contents, then I can add `/ 'Downloads' -> again, I see all the contents, etc.
If I don't resolve it immediately, I won't see neither the final file, nor will I see if I made a mistake along the way.
Do you mean FileLocator should have a gtInspector*Extension like FileReference, like copying #gtInspectorItemsIn: ? But perhaps all those extensions for different file types should be a trait to not repeat ourselves? cheers -ben
Also how is `FileLocator home` any more or less specific than `FileLocator D`? Neither is guaranteed to be the same (or even exist) for all users.
Peter
On Wed, Dec 14, 2016 at 10:25:08AM +0100, Nicolai Hess wrote:
2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak@gmail.com>:
Hi,
is there a reason why FileLocator behaves like this?
FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\)
Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
In what situation do you need to call #asFileReference ? because I thought a FileLocator should behave like a FileReference (implementingthe same api).
What is the use case that you don't want to resolve it yet?
Thanks, Peter
2016-12-14 12:05 GMT+01:00 Ben Coman <btc@openinworld.com>:
But perhaps all those extensions for different file types should be a trait to not repeat ourselves?
Problem with trait that you could not add it as class extension. Now you could package your GT support as separate package. But with trait it is not possible. It would be really nice feature by the way
On Wed, Dec 14, 2016 at 12:13:09PM +0100, Denis Kudriashov wrote:
2016-12-14 12:05 GMT+01:00 Ben Coman <btc@openinworld.com>:
But perhaps all those extensions for different file types should be a trait to not repeat ourselves?
Problem with trait that you could not add it as class extension. Now you could package your GT support as separate package. But with trait it is not possible.
It would be really nice feature by the way
Ok, so the bottom line is, we could either copy GT behavior to FileLocator, or I can at the end remove the asFileReference. In either case I still don't understand why the result is different - the arguably more stable one ($HOME) is late-bound, but windows disks that can easily change at runtime are not (i.e. (un)plugging a flash disk)? Peter
On 14 Dec 2016, at 15:14, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Wed, Dec 14, 2016 at 12:13:09PM +0100, Denis Kudriashov wrote:
2016-12-14 12:05 GMT+01:00 Ben Coman <btc@openinworld.com>:
But perhaps all those extensions for different file types should be a trait to not repeat ourselves?
Problem with trait that you could not add it as class extension. Now you could package your GT support as separate package. But with trait it is not possible.
It would be really nice feature by the way
Ok, so the bottom line is, we could either copy GT behavior to FileLocator, or I can at the end remove the asFileReference.
In either case I still don't understand why the result is different - the arguably more stable one ($HOME) is late-bound, but windows disks that can easily change at runtime are not (i.e. (un)plugging a flash disk)?
My home directory /Users/sven is not your home directory /Users/peter but they are both the logical concept of home directory The C or D drive on Windows are always the C or D drive, even if they are removable/changeable, there is no other way to refer to them - they are the same at both levels of abstraction That is how I would interpret the situation
Peter
We can just move gt methods to AbstractFileReference 2016-12-14 15:30 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 14 Dec 2016, at 15:14, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Wed, Dec 14, 2016 at 12:13:09PM +0100, Denis Kudriashov wrote:
2016-12-14 12:05 GMT+01:00 Ben Coman <btc@openinworld.com>:
But perhaps all those extensions for different file types should be a trait to not repeat ourselves?
Problem with trait that you could not add it as class extension. Now you could package your GT support as separate package. But with trait it is not possible.
It would be really nice feature by the way
Ok, so the bottom line is, we could either copy GT behavior to FileLocator, or I can at the end remove the asFileReference.
In either case I still don't understand why the result is different - the arguably more stable one ($HOME) is late-bound, but windows disks that can easily change at runtime are not (i.e. (un)plugging a flash disk)?
My home directory /Users/sven is not your home directory /Users/peter but they are both the logical concept of home directory
The C or D drive on Windows are always the C or D drive, even if they are removable/changeable, there is no other way to refer to them - they are the same at both levels of abstraction
That is how I would interpret the situation
Peter
Hi 2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak@gmail.com>:
Hi,
is there a reason why FileLocator behaves like this?
FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\)
Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
Why you need this conversion? They should be polymorphic. Idea that FileLocator gives you kind of virtual path which is independent of image location and could be resolved differently when you move your image. And message #D gives you concrete file reference because it is not virtual, it is concrete resolved path. There is also message #resolve to get actual file reference from locator.
On 14 Dec 2016, at 10:13, Peter Uhnak <i.uhnak@gmail.com> wrote:
Hi,
is there a reason why FileLocator behaves like this?
FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\)
Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
What is the use case that you don't want to resolve it yet?
I think the idea is that the first one is like $HOME, i.e. it can be different on different machines/contexts. It is a higher level abstraction that can resolve to different concrete directories. To work with these more abstract file references you just use them. (FileLocator temp / 'foo.txt') ensureCreateFile. (FileLocator temp / 'foo.txt') fullPath. Conversions happen when needed. At least, this is how I think FileSystem was designed.
Thanks, Peter
On 14 Dec 2016, at 10:13 , Peter Uhnak <i.uhnak@gmail.com> wrote:
Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
What is the use case that you don't want to resolve it yet?
To illustrate the benefit of keeping things as FileLocator instances rather than resolved paths until needed, you could try: 1) Open a playground. 2) Save image. 3) Quit, open image on different platform. In Pharo 5, your image will simply error on trying to open new Playgrounds, on Pharo6 you lose any custom locations selected in the settings for storing cache/stash. The amount of workaround code dealing with cache/stashDirectories being FileReferences instead of FileLocators is an interesting read - not to mention implemented in 2 different ways for cacheDirectory/stashDirectory; one never lets you keep a custom value (resetting to nil at startup), and the other discards any custom path when transitioning platforms. (is it not nil? does it exist? If not, reset to default) TL;DR: The use-case for FileLocators is persistently stored relative paths that need to work cross-platform. Cheers, Henry
Hi Henry, On Wed, Dec 14, 2016 at 4:20 PM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On 14 Dec 2016, at 10:13 , Peter Uhnak <i.uhnak@gmail.com> wrote:
Because now I always end up doing FileLocator home asFileReference, which feels superfluous.
What is the use case that you don't want to resolve it yet?
To illustrate the benefit of keeping things as FileLocator instances rather than resolved paths until needed, you could try: 1) Open a playground. 2) Save image. 3) Quit, open image on different platform.
In Pharo 5, your image will simply error on trying to open new Playgrounds, on Pharo6 you lose any custom locations selected in the settings for storing cache/stash. The amount of workaround code dealing with cache/stashDirectories being FileReferences instead of FileLocators is an interesting read - not to mention implemented in 2 different ways for cacheDirectory/stashDirectory; one never lets you keep a custom value (resetting to nil at startup), and the other discards any custom path when transitioning platforms. (is it not nil? does it exist? If not, reset to default)
This is an interesting observation. I'd love to simplify the code in that part. Can you open a bug report with this info so it's not lost. Cheers, Andrei
TL;DR: The use-case for FileLocators is persistently stored relative paths that need to work cross-platform.
Cheers, Henry
participants (7)
-
Andrei Chis -
Ben Coman -
Denis Kudriashov -
Henrik Johansen -
Nicolai Hess -
Peter Uhnak -
Sven Van Caekenberghe