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