Hi Guillermo, On Fri, Jun 30, 2017 at 10:12:32AM +0200, Guillermo Polito wrote:
On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Rajula, thanks for your write-up.
As the person who pushed Rajula to send his email I feel I should respond.
While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on:
'../init/mystartup.st' asFileReference fileIn
to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like:
(FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn
That's not true. It depends from where the image is launched. If you're running from the command line,
$ pharo Pharo.image eval " 'someFile' asFileReference fullName "
will be a file relative to the path of the image, if you open the image from where it is located (ie, working directory = image directory).
Feel free to ignore this section, it isn't important to the conclusion... But that's my point - it depends on where the image is launched. If I want to be sure that the file will be found, I need to resolve from the image directory, not the process current working directory. Using the current definition of defaultWorkingDirectory I don't need to worry about this.
This is yes different when you're 1) deploying the image in one directory, but you're using it from another one $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' asFileReference fullName "
But then, why working directory should be image directory and not VM directory? Just historical reasons? That's a buggy convention. And people who know what a working directory is will perceive it as even buggier.
2) starting the process from a graphical environment (ie, double click in an executable app) In that case, the OS usually sets as working directory the current user home directory, or the user "desktop" directory.
In any case, - we should have a good default, I think that following the principle of least surprise we should use as working directory what the OS means by working directory.
This is the important bit on which we all seem to agree. :-)
- Applications in general should be explicit with their file management. Each OS has different locations to store different things (data, settings, libraries, executables)... FileLocator helps by reducing the noise between different OSs, but we should use it!
:-) Cheers, Alistair