Smalltalk › Pharo › Pharo Smalltalk Developers

Lazy File Opening in FileHandle

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Pharo Smalltalk Developers mailing list

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

Martin McClure-2

Re: Lazy File Opening in FileHandle

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

Guillermo Polito

Re: Lazy File Opening in FileHandle

Hi all,

On Fri, Jan 4, 2019 at 12:26 AM Martin McClure <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Guillermo Polito

Re: Lazy File Opening in FileHandle

On Fri, Jan 4, 2019 at 12:26 AM Martin McClure <[hidden email]> 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.