[Pharo-project] 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
wooohooo!! :) On 02.08.2012, at 13:13, Esteban Lorenzano <estebanlm@gmail.com> 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
Yeahhhhh! Max Leske <maxleske@gmail.com> writes:
wooohooo!! :)
On 02.08.2012, at 13:13, Esteban Lorenzano <estebanlm@gmail.com> 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
Pharo is getting less religious :) ps: less god objects ;) On Thu, Aug 2, 2012 at 1:54 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:
On Thu, Aug 2, 2012 at 1:13 PM, Esteban Lorenzano <estebanlm@gmail.com>
wrote: (and almost the only)
yet :^)
Cheers,
Esteban
-- Mariano http://marianopeck.wordpress.com
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.
On Thu, Aug 2, 2012 at 10:11 AM, Sean P. DeNigris <sean@clipperadams.com>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.
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
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 <stephane.ducasse@inria.fr> 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
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 <stephane.ducasse@inria.fr> 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
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:
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 <stephane.ducasse@inria.fr> 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
- 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).
On Aug 2, 2012, at 9:29 PM, Chris Muller <asqueaker@gmail.com> 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
participants (10)
-
Bernardo Ezequiel Contreras -
Camillo Bruni -
Chris Muller -
Esteban Lorenzano -
Guillermo Polito -
Mariano Martinez Peck -
Max Leske -
petton.nicolas＠gmail.com -
Sean P. DeNigris -
Stéphane Ducasse