From: Brad <BCoish@...>
Date: 2004-07-03T01:17:47+09:00
Subject: Re: Extending The File Class

Robert Klemme wrote:

> 
> "Brad" <BCoish@Dymaxion.com> schrieb im Newsbeitrag
> news:zgeFc.15584$vO1.103757@nnrp1.uunet.ca...
> > 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
> 
> 
> > 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:

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. :)