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