Smalltalk › Pharo › Pharo Smalltalk Developers

inconsistent FileLocator behavior

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Peter Uhnak

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

Nicolai Hess-3-2

Re: inconsistent FileLocator behavior

2016-12-14 10:13 GMT+01:00 Peter Uhnak <[hidden email]>:

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

Nicolai Hess-3-2

Re: inconsistent FileLocator behavior

In reply to this post by Peter Uhnak

2016-12-14 10:13 GMT+01:00 Peter Uhnak <[hidden email]>:

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

Denis Kudriashov

Re: inconsistent FileLocator behavior

In reply to this post by Peter Uhnak

2016-12-14 10:13 GMT+01:00 Peter Uhnak <[hidden email]>:

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.

Sven Van Caekenberghe-2

Re: inconsistent FileLocator behavior

In reply to this post by Peter Uhnak

> On 14 Dec 2016, at 10:13, Peter Uhnak <[hidden email]> 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
>
>

Peter Uhnak

Re: inconsistent FileLocator behavior

In reply to this post by Nicolai Hess-3-2

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 <[hidden email]>:
>
> > 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
> >
> >
> >

Ben Coman

Re: inconsistent FileLocator behavior

On Wed, Dec 14, 2016 at 6:18 PM, Peter Uhnak <[hidden email]> 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 <[hidden email]>:
>
> > 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
> >
> >
> >

Denis Kudriashov

Re: inconsistent FileLocator behavior

2016-12-14 12:05 GMT+01:00 Ben Coman <[hidden email]>:

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

Peter Uhnak

Re: inconsistent FileLocator behavior

On Wed, Dec 14, 2016 at 12:13:09PM +0100, Denis Kudriashov wrote:

> 2016-12-14 12:05 GMT+01:00 Ben Coman <[hidden email]>:
>
> > 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

Sven Van Caekenberghe-2

Re: inconsistent FileLocator behavior

> On 14 Dec 2016, at 15:14, Peter Uhnak <[hidden email]> wrote:
>
> On Wed, Dec 14, 2016 at 12:13:09PM +0100, Denis Kudriashov wrote:
>> 2016-12-14 12:05 GMT+01:00 Ben Coman <[hidden email]>:
>>
>>> 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
>

Denis Kudriashov

Re: inconsistent FileLocator behavior

We can just move gt methods to AbstractFileReference

2016-12-14 15:30 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:

> On 14 Dec 2016, at 15:14, Peter Uhnak <[hidden email]> wrote:
>
> On Wed, Dec 14, 2016 at 12:13:09PM +0100, Denis Kudriashov wrote:
>> 2016-12-14 12:05 GMT+01:00 Ben Coman <[hidden email]>:
>>
>>> 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
>

Henrik Sperre Johansen

Re: inconsistent FileLocator behavior

In reply to this post by Peter Uhnak

> On 14 Dec 2016, at 10:13 , Peter Uhnak <[hidden email]> 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

Andrei Chis

Re: inconsistent FileLocator behavior

Hi Henry,

On Wed, Dec 14, 2016 at 4:20 PM, Henrik Johansen <[hidden email]> wrote:

> On 14 Dec 2016, at 10:13 , Peter Uhnak <[hidden email]> 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