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

Denis Kudriashov dionisiydk at gmail.com
Tue Oct 3 09:14:26 EDT 2017


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

> But the packaging is not an issue. I think Denis proposed to put such
> methods as extension methods. So they will belong to the correct package.
> Isn't it?
>

Yes


>
> On Tue, Oct 3, 2017 at 3:08 PM, Denis Kudriashov <dionisiydk at gmail.com>
> wrote:
>
>> Hi Henrik.
>>
>> 2017-10-03 14:04 GMT+02:00 Henrik Sperre Johansen <
>> henrik.s.johansen at veloxit.no>:
>>
>>> -1 from me, for the same reasons we moved away from Framework Settings as
>>> extension methods on a central "Settings" class.
>>>
>>
>> I think the reason was not only this.
>> In most cases settings affect class variables which provide default
>> values for instances. So it is just suitable to define settings in same
>> place where state is defined.
>> Also it not breaks encapsulation.
>>
>> And in case of FileLocator it will not access anybody state. It is about
>> constant file paths.
>>
>>
>>> Keep "globals" related to a package local to the package where they are
>>> used.
>>>
>>
>> I just want practical solution. Now there are no tools to browse what
>> files are used by applications. And simple convention could be good enough.
>>
>>
>>> Cheers,
>>> Henry
>>>
>>>
>>>
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.ht
>>> ml
>>>
>>>
>>>
>
>
> --
>
>
>
> 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/e8a1aea5/attachment-0002.html>


More information about the Pharo-dev mailing list