Smalltalk › Pharo › Pharo Smalltalk Developers

R.I.P. FileDirectory

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

EstebanLM

R.I.P. FileDirectory

Hi,

In update 20240 we finally completed the unload of FileDirectory. From now, just FileSystem is available to manipulate files... AFAIK, this is the biggest (and almost the only) "incompatible" change from 1.4 to 2.0, so I recommend framework developers to start your migration right now, so they are usable by 2.0.
Don't wait until it is to late! :)
(Also, that can be useful to detect FileSystem bugs now, and not next year)

Cheers,
Esteban

Max Leske

Re: R.I.P. FileDirectory

wooohooo!! :)

On 02.08.2012, at 13:13, Esteban Lorenzano <[hidden email]> wrote:

> Hi,
>
> In update 20240 we finally completed the unload of FileDirectory. From now, just FileSystem is available to manipulate files... AFAIK, this is the biggest (and almost the only) "incompatible" change from 1.4 to 2.0, so I recommend framework developers to start your migration right now, so they are usable by 2.0.
> Don't wait until it is to late! :)
> (Also, that can be useful to detect FileSystem bugs now, and not next year)
>
> Cheers,
> Esteban

Nicolas Petton

Re: R.I.P. FileDirectory

Yeahhhhh!

Max Leske <[hidden email]> writes:

> wooohooo!! :)
>
>
> On 02.08.2012, at 13:13, Esteban Lorenzano <[hidden email]> wrote:
>
>> Hi,
>>
>> In update 20240 we finally completed the unload of
>> FileDirectory. From now, just FileSystem is available to manipulate
>> files... AFAIK, this is the biggest (and almost the only)
>> "incompatible" change from 1.4 to 2.0, so I recommend framework
>> developers to start your migration right now, so they are usable by
>> 2.0.
>> Don't wait until it is to late! :)
>> (Also, that can be useful to detect FileSystem bugs now, and not next year)
>>
>> Cheers,
>> Esteban
>
>

--
Nicolas Petton
http://nicolas-petton.fr

Guillermo Polito

Re: R.I.P. FileDirectory

In reply to this post by EstebanLM

On Thu, Aug 2, 2012 at 1:13 PM, Esteban Lorenzano <[hidden email]> wrote:
(and almost the only)

yet :^)

Cheers,
Esteban

Mariano Martinez Peck

Re: R.I.P. FileDirectory

Pharo is getting less religious :)

ps: less god objects ;)

On Thu, Aug 2, 2012 at 1:54 PM, Guillermo Polito <[hidden email]> wrote:

On Thu, Aug 2, 2012 at 1:13 PM, Esteban Lorenzano <[hidden email]> wrote:
(and almost the only)

yet :^)

Cheers,
Esteban

--
Mariano
http://marianopeck.wordpress.com

Sean P. DeNigris

Re: R.I.P. FileDirectory

Administrator

In reply to this post by EstebanLM

EstebanLM wrote

we finally completed the unload of FileDirectory

Dear FileDirectory, enjoy your retirement... I will not miss you.

Cheers,
Sean

vonbecmann

Re: R.I.P. FileDirectory

On Thu, Aug 2, 2012 at 10:11 AM, Sean P. DeNigris <[hidden email]> wrote:

EstebanLM wrote

>
> we finally completed the unload of FileDirectory

Dear FileDirectory, enjoy your retirement... I will not miss you.

--
View this message in context: http://forum.world.st/R-I-P-FileDirectory-tp4642641p4642658.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

--
Bernardo E.C.

Awesome[1].jpg (54K) Download Attachment

Stéphane Ducasse

Re: R.I.P. FileDirectory

I always wanted to get rid of it. Now there is a difference between wanting and doing :)
and I should say that we should thank two persons: colin for releasing his code (once we have some kind of metadata for package - relay soon we should not forget to mention that he built the first version and camillo for pushing like a crazy to get Filesystem used everywhere.
Of course we should thank also guillermo and esteban for the steady, positively aggressive attitude against old code.

So this is cool to see that happing.

PS: I have other dreams :).

Stef

Camillo Bruni-3

Re: R.I.P. FileDirectory

Finally we did it, that were some hours of hard work :P.
Now we have to provide some help to those people who port their code...

Certainly some of you might request a compat package for FileDirectory.
There are certain issues with that:

- FileDirectory is implemented like a C library
- FileSystem is implemented in a OO way with lots of delegation

- FileDirectory uses Strings as path descriptions, FileSystem uses real Objects for that.
- The main entry point for FileSystem is the FileReference, the old way is String + FileDirectory

so we have a total inversion of control compared to the old FileDirectory which
will make it hard to maintain a real compatibility package.

Furthermore I have seen how much ugly and bad code the old FileDirectory has
caused, believe me it is worth the effort to spend a little time to rewrite your
library! You will avoid so much useless code!

We will sit together these days to see what we can do to limit the efforts
of porting old code.

best
cami

On 2012-08-02, at 19:53, Stéphane Ducasse <[hidden email]> wrote:

>
> I always wanted to get rid of it. Now there is a difference between wanting and doing :)
> and I should say that we should thank two persons: colin for releasing his code (once we have some kind of metadata for package - relay soon we should not forget to mention that he built the first version and camillo for pushing like a crazy to get Filesystem used everywhere.
> Of course we should thank also guillermo and esteban for the steady, positively aggressive attitude against old code.
>
> So this is cool to see that happing.
>
> PS: I have other dreams :).
>
> Stef

Stéphane Ducasse

Re: R.I.P. FileDirectory

may be a nice parseTree write bunch of rules may help

Stef

On Aug 2, 2012, at 8:00 PM, Camillo Bruni wrote:

> Finally we did it, that were some hours of hard work :P.
> Now we have to provide some help to those people who port their code...
>
> Certainly some of you might request a compat package for FileDirectory.
> There are certain issues with that:
>
> - FileDirectory is implemented like a C library
> - FileSystem is implemented in a OO way with lots of delegation
>
> - FileDirectory uses Strings as path descriptions, FileSystem uses real Objects for that.
> - The main entry point for FileSystem is the FileReference, the old way is String + FileDirectory
>
> so we have a total inversion of control compared to the old FileDirectory which
> will make it hard to maintain a real compatibility package.
>
> Furthermore I have seen how much ugly and bad code the old FileDirectory has
> caused, believe me it is worth the effort to spend a little time to rewrite your
> library! You will avoid so much useless code!
>
> We will sit together these days to see what we can do to limit the efforts
> of porting old code.
>
> best
> cami
>
>
> On 2012-08-02, at 19:53, Stéphane Ducasse <[hidden email]> wrote:
>
>>
>> I always wanted to get rid of it. Now there is a difference between wanting and doing :)
>> and I should say that we should thank two persons: colin for releasing his code (once we have some kind of metadata for package - relay soon we should not forget to mention that he built the first version and camillo for pushing like a crazy to get Filesystem used everywhere.
>> Of course we should thank also guillermo and esteban for the steady, positively aggressive attitude against old code.
>>
>> So this is cool to see that happing.
>>
>> PS: I have other dreams :).
>>
>> Stef
>
>

Stéphane Ducasse

Re: R.I.P. FileDirectory

In reply to this post by Camillo Bruni-3

camillo

it would be good to get a chapter (or update a bit the one we have) on filesystem.
Because already having a cool set of examples can help a lot.

Stef
On Aug 2, 2012, at 8:00 PM, Camillo Bruni wrote:

Chris Muller-3

Re: R.I.P. FileDirectory

In reply to this post by Camillo Bruni-3

> - FileDirectory uses Strings as path descriptions, FileSystem uses real Objects for that.

Nope, it uses DirectoryEntry.

> - The main entry point for FileSystem is the FileReference, the old way is String + FileDirectory

No, DirectoryEntry is like a FileReference. But some folks may prefer
just to use simple Strings in some cases. Strings are a *real* part
of any modern filesystem domain, so you've got to deal with them at
SOME point. And, since there is shorthand syntax for Strings
understood by the Compiler, it can actually make code *cleaner* in
some cases than having to instantiate an object model every time just
to, for example, get a list of directory contents (not to mention
allocation expense).

EstebanLM

Re: R.I.P. FileDirectory

On Aug 2, 2012, at 9:29 PM, Chris Muller <[hidden email]> wrote:

>> - FileDirectory uses Strings as path descriptions, FileSystem uses real Objects for that.
>
> Nope, it uses DirectoryEntry.
>
>> - The main entry point for FileSystem is the FileReference, the old way is String + FileDirectory
>
> No, DirectoryEntry is like a FileReference. But some folks may prefer
> just to use simple Strings in some cases. Strings are a *real* part
> of any modern filesystem domain, so you've got to deal with them at
> SOME point. And, since there is shorthand syntax for Strings
> understood by the Compiler, it can actually make code *cleaner* in
> some cases than having to instantiate an object model every time just
> to, for example, get a list of directory contents (not to mention
> allocation expense).
>

It is a matter of taste, or maybe not, which design is better.
Maybe FD uses DE, but that is internally. In your programs, you do: FileDirectory on: 'a/path/to/a/file', which gives you a FileDirectory instance, on which you can do operations, like a C library. For instance, FileDirectory default readOnlyFileNamed: 'Blah'. Unless you uses specifically #entries, you never see the DE instances...
With FileSystem, you have the reference concept reified into something that represents a file entry, and that object can understand operations related to a file reference.
In the same example, with FileSystem you do: 'blah' asFileReference readStream. That of course, gives you the easy of using strings, in a much better design, IMO.

Also, DirectoryEntry is *not* like FileReference... maybe in their intentions, but for real DE works more like a data structure with no much behavior remaining (for instance, a DirectoryEntryDirectory cannot give you the directory entries, you have to go back to a FileDirectory to do that).

Notice that even FileDirectory creates internally DirectoryEntry instances (as you said), so... the optimization you claim does not occur there either, unless I'm missing something (?)

I do believe FileSystem design can be improved, but I think is a huge step in the right direction.

Cheers,
Esteban