[Pharo-dev] Should we always put application file paths into FileLocator?

Denis Kudriashov dionisiydk at gmail.com
Tue Oct 3 10:05:39 EDT 2017


2017-10-03 15:52 GMT+02:00 Guillermo Polito <guillermopolito at gmail.com>:

> Sure, but then why FileLocator?
>

Because I do not want to browse all code of Epicea (for example) to find
where the files are placed.
Maybe we can build tool for this. But with FileLocator I will find it
immediately.


> You could have in your app a normal class for that... I see you're
> creating a dependency for no real value, or even just polluting FileLocator
> for polluting it... I mean, to me the real value of FileLocator is to give
> you the cross-platform feature.
>


>
> On Tue, Oct 3, 2017 at 3:41 PM, Denis Kudriashov <dionisiydk at gmail.com>
> wrote:
>
>>
>>
>> 2017-10-03 15:22 GMT+02:00 Guillermo Polito <guillermopolito at gmail.com>:
>>
>>>
>>>
>>> On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <dionisiydk at gmail.com>
>>> wrote:
>>>
>>>>
>>>> 2017-10-03 13:54 GMT+02:00 Guillermo Polito <guillermopolito at gmail.com>
>>>> :
>>>>
>>>>> Could you write a blog post? :D
>>>>>
>>>>> - What is the good practice
>>>>> - extending FileLocator
>>>>> - managing paths in a platform independent way (what to extend for
>>>>> unix, mac, windows, default values for unknown platforms...)
>>>>>
>>>>
>>>> I am not sure about last point. I thought it is solved by FileSystem
>>>> itself.
>>>>
>>>
>>> Nope, check FileLocator. FileLocator was actually designed for that, not
>>> to be a "place holder" for paths.
>>>
>>
>> I know. But I am talking only about "place holder" parts.
>> If my app wants myApp.config in image directory  I would put it in
>> FileLocator like this:
>>
>> FileLocator class>>myAppConfig
>>
>> "method in my app package"
>>
>> ^self imageDirectory / 'myApp.config'
>>
>>
>> Nothing complex and intelligent here.
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <
>>>>> dionisiydk at gmail.com> wrote:
>>>>>
>>>>>> Ok. No objections yet.
>>>>>> I will prepare pull requests
>>>>>>
>>>>>> 2017-10-03 12:04 GMT+02:00 Guillermo Polito <
>>>>>> guillermopolito at gmail.com>:
>>>>>>
>>>>>>> Yes yes yes
>>>>>>>
>>>>>>> On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <
>>>>>>> stepharo.self at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi denis
>>>>>>>>
>>>>>>>> I like it!.
>>>>>>>>
>>>>>>>> Stef
>>>>>>>>
>>>>>>>> On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <
>>>>>>>> dionisiydk at gmail.com> wrote:
>>>>>>>> > Hi.
>>>>>>>> >
>>>>>>>> > Many times I was trying to find "global" files of some packages
>>>>>>>> in system.
>>>>>>>> >
>>>>>>>> > For example do you know how to find epicea session logs?
>>>>>>>> > There is class side method for this at EpMonitor:
>>>>>>>> >
>>>>>>>> > EpMonitor logsDirectory
>>>>>>>> >
>>>>>>>> > Is it easy to find when you never look at it? No.
>>>>>>>> >
>>>>>>>> > Do you know how to find sources file? There is message in
>>>>>>>> Smalltalk global:
>>>>>>>> >
>>>>>>>> > Smalltalk sourcesFile
>>>>>>>> >
>>>>>>>> > Is it easy to find? No.
>>>>>>>> >
>>>>>>>> > And there are many other examples.
>>>>>>>> >
>>>>>>>> > But if you read about FileSystem library. You know the common
>>>>>>>> place where to
>>>>>>>> > find well known files. It is FileLocator.
>>>>>>>> > For example changes file is here:
>>>>>>>> >
>>>>>>>> > FileLocator changes.
>>>>>>>> >
>>>>>>>> > So my idea is to introduce kind of pattern, the good style, how
>>>>>>>> to access
>>>>>>>> > global application files: they should be in FileLocator as
>>>>>>>> extensions.
>>>>>>>> > Then it would be super easy to find files of any applications.
>>>>>>>> >
>>>>>>>> > What do you think?
>>>>>>>> >
>>>>>>>> > If it is good idea then we should fix current places in system to
>>>>>>>> follow
>>>>>>>> > this pattern.
>>>>>>>> >
>>>>>>>> > Best regards,
>>>>>>>> > Denis
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Guille Polito
>>>>>>>
>>>>>>> Research Engineer
>>>>>>>
>>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>>>>>
>>>>>>> CRIStAL - UMR 9189
>>>>>>>
>>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr
>>>>>>> <http://www.cnrs.fr>*
>>>>>>>
>>>>>>>
>>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>>>>>>
>>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>> Guille Polito
>>>>>
>>>>> Research Engineer
>>>>>
>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>>>
>>>>> CRIStAL - UMR 9189
>>>>>
>>>>> French National Center for Scientific Research - *http://www.cnrs.fr
>>>>> <http://www.cnrs.fr>*
>>>>>
>>>>>
>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>>>>
>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> Guille Polito
>>>
>>> Research Engineer
>>>
>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>
>>> CRIStAL - UMR 9189
>>>
>>> French National Center for Scientific Research - *http://www.cnrs.fr
>>> <http://www.cnrs.fr>*
>>>
>>>
>>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>>
>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171003/d1c954aa/attachment-0002.html>


More information about the Pharo-dev mailing list