Files as Objects / A comment for discussion

[kostas85]

Dear All,

Since Fortran tends to be more and more object-oriented, I consider to be useful to have some kind of default objects that are related to external files. For example a default type external_file that:
A. holds data related to the file, such as the integer:unit, logical:opened, logical:exists its specifiers
B. legacy subroutines are now type-bound procedures open,close,inquire

I think that this could provide an improved functionality. For example, the files a program/subprogram is using, can be clearly stated in the declarations type(external_file) :: my_input, my_output. Another example is generating and managing many files simultaneously while at the same time it provides very simple bookkeeping mechanics. Say for example that I need a variable number of files to be opened, then this could be something like type(external_file), dimension(:), allocatable :: my_files. Moreover consider a case that I would like all of these files to have the same specifiers. I could define them all at once in the beginning of the code, e.g. my_files%access="stream". So let me know what is your opinion, do you think that it would be a useful Fortran feature? 

Thanks for sharing!

Kostas

( NOTE: In the new "User and Reference Guide", table of the open statement specifiers, the "stream" keyword is missing http://software.intel.com/en-us/node/465332 )

[Kevin_D_Intel]

Thank you for the note regarding the missing STREAM value for the ACCESS specifier in the OPEN statement specifiers table. I reported this to our Documentation team for correcting in a future release.

(Internal tracking id: DPD200254004)

[IanH]

You can ... sort of ... write your own types to do this now.  Sort of - the language has a few gaps in terms of guarantees for the lifetimes of objects that mean you can't get quite the same robustness for this sort of "object manages a resource" model as you might get in other languages.

The other obvious gap is that you don't have the syntax support for things like the io-lists in write and read statements.  Use of user defined or overloaded operators, a-la C++, runs quite contrary to the usual Fortran idiom.

[FortranFan]

Good suggestion, food for thought.

I'll place native objects for XML processing also in the same category.  My little computing world sees increasing use of XML for all kinds of data exchange in engineering and scientific applications; each domain has developed its own ways, often using mixed-language solutions, for creating and consuming XML objects.  This is along the lines of IanH's suggestion on file objects i.e., one can develop one own's solutions (classes/types, however you want to call it) and either live with the gaps in the language or bridge it somehow using some external means.  But problems do arise with these multiple and sometimes disparate ways and besides, there are learning barriers for new users.  Built-in options in Fortran might make things a lot easier.

I wonder if this is where some compiler vendors can offer some extensions which eventually become part of the standard, similar to how namelist processing was available as an extension for a long time before getting merged into the language.

[kostas85]

Hello and thank you both for your feedback!

Yes you can write your own "utility" modules for having a similar behavior, and I think that is quite a good exercise for learning more about Fortran objects and how they work. Moreover, you can handle situations that you encounter in a daily basis as a "modern" Fortran programmer. However, there are many, lets say "legacy" Fortran programmers, that say that since what I have is working I shouldn't mess up with it but when they find something easy to use and providing some extra functionality they tend to use it (say for example the newunit specifier). So I, also, believe that having an intrinsic support for the "file" object could be "simple to use" and "basic" examples of how objects can aid your programming. Of course one still needs to know the relative details afterwards,