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