[Os-project-managers] Consent agenda item

Horand Gassmann Horand.Gassmann at DAL.CA
Wed Sep 21 15:03:09 EDT 2011


"R. Kipp Martin" <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>>
>> We currently have a class OSnl2osil in files OSnl2osil.cpp and
>> OSnl2osil.h. Its purpose is to read a .nl file and to pull out the
>> instance information. However, as we have seen, the .nl file also
>> contains bits and pieces that we would classify as options. ASL gives us
>> only very limited access through its API, so we have to parse the entire
>> .nl file to get at any piece of it. We therefore have to pull the
>> OSOption bits out simultaneously with the OSInstance pieces. (Otherwise
>> the time may kill us on a large problem.)
>>
>> I propose to define a new class nl2OS _inside_ the same OSnl2osil.cpp/.h
>> files. This class would inherit from OSnl2osil, and so everything would
>> be backwards compatible. It would also make the code development easier.
>>
>> Is this reasonable? Please feel free to consent/object/discuss.
>
> A few thoughts:
>
> 1) I definitely agree we should not do two separate reads of the nl  
> file, one for the instance and one for the options
>
> 2) To be honest, I think it is misleading to have the OSnl2osil have  
> "hidden" code that also creates an OSOption object. Also, the  
> inheritance seems odd and awkward. The class OSnl2osil creates osil  
> from nl.  To have a class that inherits from this that either  
> creates osil and osol or just osol does not make any sense to me.
>
> 3) I would like to propose the following alternative:
>
> a) keep OSnl2osil.cpp and OSnl2osil.h exactly as is. This will be  
> legacy code that may or may not get deleted at some future point. I  
> don't think this is an uncommon practice.
>
> b) create a new class OSnl2OS that reads the nl file once and pulls  
> out the instance and the options. Of course we can cut and paste any  
> code we want from OSnl2osil here.
>
> c) we modify OSAmlClient to use OSnl2OS.
>
> With the above changes then we are completely backward compatible,  
> keep all the old functionality and have new and improved  
> functionality.

That was exactly the point I was worried about. What if "someone" has  
code out there that #uses OSnl2osil.h? That code will break. If that's  
OK, then surely I support your proposal.

Cheers

gus



More information about the Os-project-managers mailing list