Lazy File Opening in FileHandle
Guille, In FileHandle there is a concept of a lazy file opening in FileHandle>>#at:read:startingAt:count FileHandle>>#at:write:startingAt:count where the method FileHandle>>#assureOpen is called. Based on out previous conversations I believe that this concept is to be deprecated. Can you please confirm. Regards, Reg
Hi Reg, It looks to me like the lazy opening functionality is unused in Pharo 7, and is not reachable when using the documented "new" API. (Somewhat oddly, one of the more complete documentations of what's recommended seems to be the class comment of the deprecated class FileStream.) Lazy opening is rather odd conceptually, and doesn't seem to meet the principle of least surprise, so I'd think deprecating it would be reasonable. Regards, -Martin On 1/2/19 9:15 AM, Reg Krock wrote:
Guille,
In FileHandle there is a concept of a lazy file opening in
FileHandle>>#at:read:startingAt:count FileHandle>>#at:write:startingAt:count
where the method FileHandle>>#assureOpen is called.
Based on out previous conversations I believe that this concept is to be deprecated.
Can you please confirm.
Regards,
Reg
Hi all, On Fri, Jan 4, 2019 at 12:26 AM Martin McClure <martin@hand2mouse.com> wrote:
Hi Reg,
It looks to me like the lazy opening functionality is unused in Pharo 7, and is not reachable when using the documented "new" API.
And I think it never was... or I least I don't remember it being used. Actually the only way to get a file handle is on an (in theory) already open file. See for example that the only place where file handles are instantiated are in open: aResolvable writable: aBoolean "Resolve aResolvable into an absolute path, then ask the store to open the file at that path using the specified access mode." | path | path := self resolve: aResolvable. ^ store handleClass open: (FileReference fileSystem: self path: path) writable: aBoolean
(Somewhat oddly, one of the more complete documentations of what's recommended seems to be the class comment of the deprecated class FileStream.)
Well, this thing grew a bit organically. I bet Pavel put that comment there :)
Lazy opening is rather odd conceptually, and doesn't seem to meet the principle of least surprise, so I'd think deprecating it would be reasonable.
Agreed. Personally I think FileHandle needs some cleanup, to me it looks strange that it acquires a vm file handle, and then it operates on it through primitives, when the File class already does that properly.
Regards,
-Martin
On 1/2/19 9:15 AM, Reg Krock wrote:
Guille,
In FileHandle there is a concept of a lazy file opening in
FileHandle>>#at:read:startingAt:count FileHandle>>#at:write:startingAt:count
where the method FileHandle>>#assureOpen is called.
Based on out previous conversations I believe that this concept is to be deprecated.
Can you please confirm.
Regards,
Reg
-- 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
On Fri, Jan 4, 2019 at 12:26 AM Martin McClure <martin@hand2mouse.com> wrote:
Lazy opening is rather odd conceptually, and doesn't seem to meet the principle of least surprise, so I'd think deprecating it would be reasonable.
Agreed. Personally I think FileHandle needs some cleanup, to me it looks strange that it acquires a vm file handle, and then it operates on it through primitives, when the File class already does that properly.
And even just change the code to do it in a non-lazy way. I don't think the lazy opening is exposed through any of FileSystem's API.
participants (3)
-
Guillermo Polito -
Martin McClure -
Reg Krock