Smalltalk › Pharo › Pharo Smalltalk Developers

Should we always put application file paths into FileLocator?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Denis Kudriashov

Should we always put application file paths into FileLocator?

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

Sean P. DeNigris

Re: Should we always put application file paths into FileLocator?

Administrator

Denis Kudriashov wrote
> What do you think?

It makes sense to me to have a single uniform access point for system files.

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Cheers,
Sean

Stephane Ducasse-3

Re: Should we always put application file paths into FileLocator?

In reply to this post by Denis Kudriashov

Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Guillermo Polito

Re: Should we always put application file paths into FileLocator?

Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:

Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Denis Kudriashov

Re: Should we always put application file paths into FileLocator?

Ok. No objections yet.

I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:

Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Guillermo Polito

Re: Should we always put application file paths into FileLocator?

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...)

On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <[hidden email]> wrote:

Ok. No objections yet.
I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:
Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Henrik Sperre Johansen

Re: Should we always put application file paths into FileLocator?

In reply to this post by Denis Kudriashov

Denis Kudriashov 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

-1 from me, for the same reasons we moved away from Framework Settings as
extension methods on a central "Settings" class.
Keep "globals" related to a package local to the package where they are
used.

Cheers,
Henry

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Denis Kudriashov

Re: Should we always put application file paths into FileLocator?

Hi Henrik.

2017-10-03 14:04 GMT+02:00 Henrik Sperre Johansen <[hidden email]>:

-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.html

Guillermo Polito

Re: Should we always put application file paths into FileLocator?

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?

On Tue, Oct 3, 2017 at 3:08 PM, Denis Kudriashov <[hidden email]> wrote:

Hi Henrik.

2017-10-03 14:04 GMT+02:00 Henrik Sperre Johansen <[hidden email]>:
-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.html

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Denis Kudriashov

Re: Should we always put application file paths into FileLocator?

2017-10-03 15:13 GMT+02:00 Guillermo Polito <[hidden email]>:

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 <[hidden email]> wrote:
Hi Henrik.

2017-10-03 14:04 GMT+02:00 Henrik Sperre Johansen <[hidden email]>:
-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.html

--

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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Denis Kudriashov

Re: Should we always put application file paths into FileLocator?

In reply to this post by Guillermo Polito

2017-10-03 13:54 GMT+02:00 Guillermo Polito <[hidden email]>:

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.

On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <[hidden email]> wrote:
Ok. No objections yet.
I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:
Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Guillermo Polito

Re: Should we always put application file paths into FileLocator?

On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <[hidden email]> wrote:

2017-10-03 13:54 GMT+02:00 Guillermo Polito <[hidden email]>:
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.

On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <[hidden email]> wrote:
Ok. No objections yet.
I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:
Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Denis Kudriashov

Re: Should we always put application file paths into FileLocator?

2017-10-03 15:22 GMT+02:00 Guillermo Polito <[hidden email]>:

On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <[hidden email]> wrote:

2017-10-03 13:54 GMT+02:00 Guillermo Polito <[hidden email]>:
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 <[hidden email]> wrote:
Ok. No objections yet.
I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:
Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Guillermo Polito

Re: Should we always put application file paths into FileLocator?

Sure, but then why FileLocator? 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 <[hidden email]> wrote:

2017-10-03 15:22 GMT+02:00 Guillermo Polito <[hidden email]>:

On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <[hidden email]> wrote:

2017-10-03 13:54 GMT+02:00 Guillermo Polito <[hidden email]>:
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 <[hidden email]> wrote:
Ok. No objections yet.
I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:
Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Henrik Sperre Johansen

Re: Should we always put application file paths into FileLocator?

In reply to this post by Guillermo Polito

Guillermo Polito wrote
> 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?

The obvious counter example can be had by browsing Object.
Are the methods properly packaged? Yes. (As were Settings)
Is it likely to cause problems due to missing dependencies? No.
Is it a good OO pattern that should be should encouraged widespread use of?
IMHO, no, not if there are other options. (Separations of concern, and all
that)

(AFAICT, the role of FileLocator, is to resolve symbolic path elements at
runtime, not be a dictionary of all paths used by the base system/packages.
For that, I'd inspect Path allSubinstances + some source string searches if
I needed to find where they were defined.).

Cheers,
Henry

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Denis Kudriashov

Re: Should we always put application file paths into FileLocator?

In reply to this post by Guillermo Polito

2017-10-03 15:52 GMT+02:00 Guillermo Polito <[hidden email]>:

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 <[hidden email]> wrote:

2017-10-03 15:22 GMT+02:00 Guillermo Polito <[hidden email]>:

On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <[hidden email]> wrote:

2017-10-03 13:54 GMT+02:00 Guillermo Polito <[hidden email]>:
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 <[hidden email]> wrote:
Ok. No objections yet.
I will prepare pull requests

2017-10-03 12:04 GMT+02:00 Guillermo Polito <[hidden email]>:
Yes yes yes

On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse <[hidden email]> wrote:
Hi denis

I like it!.

Stef

On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--



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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Henrik Sperre Johansen

Re: Should we always put application file paths into FileLocator?

In reply to this post by Denis Kudriashov

Denis Kudriashov wrote
> Hi Henrik.
>
> 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.

I agree there's a need for a practical solution; however, our definitions of
practical probably differs.
To me, practical is along the lines of
a) inspecting Path allInstances / searching for source hits on strings that
seem to match what I'm looking for
b) opening class references to FileLocator / Path + some
scrolling/eyeballing

The point is, this is the type of task you may do variations of 5-20 times
during a single work day; if one has to rely on
a) There being a convention
b) You being aware of the convention
c) The use you are interested in actually having followed the convention
to accomplish each, I personally prefer getting creative in use of a few
core tools*.

That said, we do have a few ways to group methods across packages based on
related functionality;
1) Method extensions on a central location (personally not a big fan, as you
may have deduced)
2) Implementing a common trait (Seems a bit heavyweight for this though)
3) Annotations/pragmas/method tags/whatever you want to call them.*
4) ?

Cheers,
Henry

*A generic annotations explorer (with dropdown / autocompletion of known
annotations, and filtering on the different arg values) would be a core tool
I'd be interested in using.
It could also act as a driver for adhering to said convention of method tags
for cross-package categorization, not just for methods specifying file
names, but in other areas as well.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html