- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] inconsistent FileLocator behavior

by Denis Kudriashov

2016-12-14 12:05 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > But perhaps all those extensions for different file types should be a > trait to not repeat ourselves? > Problem with trait that you could not add it as class extension. Now you could package your GT support as separate package. But with trait it is not possible. It would be really nice feature by the way

Dec. 14, 2016

Re: [Pharo-dev] inconsistent FileLocator behavior

by Ben Coman

On Wed, Dec 14, 2016 at 6:18 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > It is polymorphic, but the usability suffers (at least for me). > > Imagine that I want to pick a path to specific file - for example > something in Downloads folder. > > If I don't have the full path at my hand, I open the playground and type > > FileLocator home asFileReference -> I see all the contents, > then I can add `/ 'Downloads' -> again, I see all the contents, > etc. > > If I don't resolve it immediately, I won't see neither the final file, nor > will I see if I made a mistake along the way. > Do you mean FileLocator should have a gtInspector*Extension like FileReference, like copying #gtInspectorItemsIn: ? But perhaps all those extensions for different file types should be a trait to not repeat ourselves? cheers -ben > > Also how is `FileLocator home` any more or less specific than `FileLocator > D`? Neither is guaranteed to be the same (or even exist) for all users. > > Peter > > > > On Wed, Dec 14, 2016 at 10:25:08AM +0100, Nicolai Hess wrote: > > 2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > > > Hi, > > > > > > is there a reason why FileLocator behaves like this? > > > > > > FileLocator home -> FileLocator({home}) > > > FileLocator D -> FileReference(D:\) > > > > > > Especially the first one (this also applies to #temp and others), > > > is there a benefit in returning FileLocator instead of the path? > Because > > > now I always end up doing > > > FileLocator home asFileReference, which feels superfluous. > > > > > > > In what situation do you need to call #asFileReference ? because I > thought > > a FileLocator should behave like a FileReference (implementingthe same > api). > > > > > > > > > > What is the use case that you don't want to resolve it yet? > > > > > > Thanks, > > > Peter > > > > > > > > > > >

Dec. 14, 2016

Re: [Pharo-dev] inconsistent FileLocator behavior

by Peter Uhnak

It is polymorphic, but the usability suffers (at least for me). Imagine that I want to pick a path to specific file - for example something in Downloads folder. If I don't have the full path at my hand, I open the playground and type FileLocator home asFileReference -> I see all the contents, then I can add `/ 'Downloads' -> again, I see all the contents, etc. If I don't resolve it immediately, I won't see neither the final file, nor will I see if I made a mistake along the way. Also how is `FileLocator home` any more or less specific than `FileLocator D`? Neither is guaranteed to be the same (or even exist) for all users. Peter On Wed, Dec 14, 2016 at 10:25:08AM +0100, Nicolai Hess wrote: > 2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > > Hi, > > > > is there a reason why FileLocator behaves like this? > > > > FileLocator home -> FileLocator({home}) > > FileLocator D -> FileReference(D:\) > > > > Especially the first one (this also applies to #temp and others), > > is there a benefit in returning FileLocator instead of the path? Because > > now I always end up doing > > FileLocator home asFileReference, which feels superfluous. > > > > In what situation do you need to call #asFileReference ? because I thought > a FileLocator should behave like a FileReference (implementingthe same api). > > > > > > What is the use case that you don't want to resolve it yet? > > > > Thanks, > > Peter > > > > > >

Dec. 14, 2016

Re: [Pharo-dev] The Iceberg TechTalk recording

by Glenn CavarlÃ©

Thanks Esteban and Nicolas for sharing the recording! Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/The-Iceberg-TechTalk-recording-tp4926824p4926867.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 14, 2016

Re: [Pharo-dev] inconsistent FileLocator behavior

by Sven Van Caekenberghe

> On 14 Dec 2016, at 10:13, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > is there a reason why FileLocator behaves like this? > > FileLocator home -> FileLocator({home}) > FileLocator D -> FileReference(D:\) > > Especially the first one (this also applies to #temp and others), > is there a benefit in returning FileLocator instead of the path? 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? I think the idea is that the first one is like $HOME, i.e. it can be different on different machines/contexts. It is a higher level abstraction that can resolve to different concrete directories. To work with these more abstract file references you just use them. (FileLocator temp / 'foo.txt') ensureCreateFile. (FileLocator temp / 'foo.txt') fullPath. Conversions happen when needed. At least, this is how I think FileSystem was designed. > Thanks, > Peter > >

Dec. 14, 2016

Re: [Pharo-dev] inconsistent FileLocator behavior

by Denis Kudriashov

Hi 2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > is there a reason why FileLocator behaves like this? > > FileLocator home -> FileLocator({home}) > FileLocator D -> FileReference(D:\) > > Especially the first one (this also applies to #temp and others), > is there a benefit in returning FileLocator instead of the path? Because > now I always end up doing > FileLocator home asFileReference, which feels superfluous. > Why you need this conversion? They should be polymorphic. Idea that FileLocator gives you kind of virtual path which is independent of image location and could be resolved differently when you move your image. And message #D gives you concrete file reference because it is not virtual, it is concrete resolved path. There is also message #resolve to get actual file reference from locator.

Dec. 14, 2016

Re: [Pharo-dev] inconsistent FileLocator behavior

by Nicolai Hess

2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > is there a reason why FileLocator behaves like this? > > FileLocator home -> FileLocator({home}) > FileLocator D -> FileReference(D:\) > > Especially the first one (this also applies to #temp and others), > is there a benefit in returning FileLocator instead of the path? Because > now I always end up doing > FileLocator home asFileReference, which feels superfluous. > In what situation do you need to call #asFileReference ? because I thought a FileLocator should behave like a FileReference (implementingthe same api). > > What is the use case that you don't want to resolve it yet? > > Thanks, > Peter > > >

Dec. 14, 2016

Re: [Pharo-dev] inconsistent FileLocator behavior

by Nicolai Hess

2016-12-14 10:13 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > is there a reason why FileLocator behaves like this? > > FileLocator home -> FileLocator({home}) > FileLocator D -> FileReference(D:\) > > Especially the first one (this also applies to #temp and others), > is there a benefit in returning FileLocator instead of the path? 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? > > Thanks, > Peter > > > >From the FileLocator class comment: "I am a late-bound reference. "

Dec. 14, 2016

inconsistent FileLocator behavior

by Peter Uhnak

Hi, is there a reason why FileLocator behaves like this? FileLocator home -> FileLocator({home}) FileLocator D -> FileReference(D:\) Especially the first one (this also applies to #temp and others), is there a benefit in returning FileLocator instead of the path? 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? Thanks, Peter

Dec. 14, 2016

Re: [Pharo-dev] The Iceberg TechTalk recording

by Dimitris Chloupis

you can add an annotation for the first 10 minutes that links directly to the time the techtalk actually starts you can also link to the precise time like this https://youtu.be/AuZAFfWS34w?t=598 you can get this link by pushing the playback cursor to the time you want to link and then right click and choose Copy URL at current time On Tue, Dec 13, 2016 at 11:57 PM Nicolas Passerini <npasserini(a)gmail.com> wrote: > Maybe we could try to edit the video? Is it possible? > > 2016-12-13 21:20 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > Ah, but you need to skip until minute 10 :P > > Esteban > > > On 13 Dec 2016, at 21:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi, > > > > for those who couldnât join us, this is the recording: > > > > https://www.youtube.com/watch?v=AuZAFfWS34w > > > > I think it was a great talk :) > > > > cheers, > > Esteban > > >

Dec. 13, 2016