Extending The File Class

[Brad]

All:

I'm currently working on the OpenVMS platform and would like to
write an extension library that would encapsulate the different
OpenVMS file types (of which there are several beyond text and
binary).

What needs to be done is to pass additional parameters to the
underlying C api's fopen. fopen on OpenVMS contains parameters
not supported by the ANSI standard. The extra parameters are
used to open the various file formats supported by OpenVMS.

My thoughts are to:
1) Create a new class that inherits from the File class and simply
overload/override the open/new command.
2) Add new methods to the File class that support the parameters
that I neeed to pass through (still requires access to the
underlying C API)
3) Overload the open/new in File directly to allow optional parameters
to be passed through.

My question is:
- What needs to be done? I can figure out how to write a class using
the RAPI, but I'm not sure about what Ruby does behind the scenes
(i.e. internal states,etc)
Note: Only the open/new is required to be modified, all other
file I/O routines work the same as in ANSI C.

Any help would be appreciated.

Regards,
Brad

 

[Robert Klemme]

All:

I'm currently working on the OpenVMS platform and would like to
write an extension library that would encapsulate the different
OpenVMS file types (of which there are several beyond text and
binary).

What needs to be done is to pass additional parameters to the
underlying C api's fopen. fopen on OpenVMS contains parameters
not supported by the ANSI standard. The extra parameters are
used to open the various file formats supported by OpenVMS.

My thoughts are to:
1) Create a new class that inherits from the File class and simply
overload/override the open/new command.
2) Add new methods to the File class that support the parameters
that I neeed to pass through (still requires access to the
underlying C API)
3) Overload the open/new in File directly to allow optional parameters
to be passed through.

I'd go for 1) if the functionality is extremely special (I don't know
OpenVMS so it's up to others to judge). If that's not the case (i.e.
functionality can reasonably be expected of other OS's, too) I'd do 3) and
implement it on other platforms to either ignore flags or raise an error.
Whatever is more appropriate.

2) is the worst solution IMHO since File is cross platform but those added
methods seem to be too special (i.e. only meaningfil on OpenVMS).

Kind regards

robert

 

[Brad]

I'd go for 1) if the functionality is extremely special (I don't know
OpenVMS so it's up to others to judge). If that's not the case (i.e.
functionality can reasonably be expected of other OS's, too) I'd do 3) and
implement it on other platforms to either ignore flags or raise an error.
Whatever is more appropriate.

2) is the worst solution IMHO since File is cross platform but those added
methods seem to be too special (i.e. only meaningfil on OpenVMS).

Kind regards

robert

Robert:

Thanks for the quick reply!

I was leaning toward Option #1 myself, but I thought it would only be
fair to give the other options consideration, if only to discount them.

I appreciate the comments.

 

[gabriele renzi]

il Fri, 2 Jul 2004 17:39:11 +0200, "Robert Klemme" <[email protected]>
ha scritto::

2) is the worst solution IMHO since File is cross platform but those added
methods seem to be too special (i.e. only meaningfil on OpenVMS).

C:\Documents and Settings\nicola>ruby -e "File.readlink 'f' "
-e:1:in `readlink': The readlink() function is unimplemented on this
machine (No
tImplementedError)
from -e:1
File already provides non portrable methods, so imo, #2 is ok.

Note that the concept of File itself may not be portable

Would'nt be nice if we had a couple of File subclasses like UnixFile
NTFSFile, Reiser4File, VMSFile.. or maybe mixins?
This also forces users to avoid non portable assumptions