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