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