[MOAB-dev] Reader/Writer filename extension access

[Robert Smith]

I was not advocating passing back leaf-class pointers.  I realize that  
my 'A' option for finding extensions based on a ReaderIface*/ 
WriterIface* appears to do that but all of the code would be contained  
within ReaderWriterSet.  But on further inspection I see now that this  
option would not actually work anyway.

My 'B' option was just another virtual function on ReaderIface/ 
WriterIface to return the list of extensions handled by the Reader/ 
Writer.  This would not require the leaf-classes to be known in the  
client.  It just required another set of classes to contain the  
information pertinent to a particular leaf class Reader/Writer  
implementation set.  And those classes are only known to that  
particular Reader/Writer implementation set.

Either way, I don't think my solutions are the best given what I've  
read today.  Maybe I misunderstood the ticket. It seems that the  
proposal of a way to get the actual format type used to read in the  
file would be more useful along with the enhanced mechanism of  
specifying format specific options to the load_file function.

--Bob


On Apr 30, 2010, at 1:25 PM, Tim Tautges wrote:

> Coupla comments:
>
> - I can't think of why we'll want to pass back leaf-class pointers  
> to readers/writers through the API; parent class pointers should  
> suffice in all cases, I would think
> - In most cases I think names of the reader/writer would be  
> sufficient, and you could get those from ReaderWriterSet.
>
> - tim
>
> Jason Kraftcheck wrote:
>> Robert Smith wrote:
>>> On Apr 30, 2010, at 9:05 AM, Jed Brown wrote:
>>>
>>>> On Fri, 30 Apr 2010 09:01:09 -0500, Robert Smith <smithrm at mcs.anl.gov 
>>>> >
>>>> wrote:
>>>>> What do you mean by "not part of the MOAB API"?  We can't  
>>>>> dictate the
>>>>> structure of the Readers/Writers?
>>>> I think Jason's point was that it's unacceptable for client code  
>>>> to have
>>>> a dependency on the implementations.
>>> Do you mean the code that uses the Readers/Writers?  I would  
>>> agree, it
>>> should not depend on the implementation.  But does that mean no  
>>> client
>>> code can know which particular Reader/Writer it is using?  If that's
>>> true then the entire purpose of the ticket seems moot.
>> No, the application needs to know the file format that it wants to
>> read/write.  It does not need to have a pointer to the Reader/Writer
>> instance in MOAB that implements that file format.  For example,  
>> why not
>> instead have functions that return a list of string names for all the
>> readers and writers, and then have functions that, given a string  
>> name,
>> return the list of extensions or description.
>>> If that's not what you mean then I don't see how my suggestions  
>>> open the
>>> implementation to the users.  They are just new member functions.
>>>
>> They require that we install headers for all the reader/writer
>> implementations and that the app include those headers, effectively  
>> making
>> all of the implementations part of the MOAB API.
>> - jason
>
> -- 
> ================================================================
> "You will keep in perfect peace him whose mind is
>  steadfast, because he trusts in you."               Isaiah 26:3
>
>             Tim Tautges            Argonne National Laboratory
>         (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>         phone: (608) 263-8485      1500 Engineering Dr.
>           fax: (608) 263-4499      Madison, WI 53706
>