Re: set.q

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Tue, Dec 06, 2005 at 03:16:38PM -0800, Ben Pfaff wrote:
>      >
>      > You see the gui needs to be able to inspect the current state of
>      > things like cc_{a,e}, but I don't want it to have to depend upon the
>      > code for parsing the SET command (or any of the lexer stuff).
>      
>      I think the real problem here is that we have two purposes, which
>      are parsing and storage of settings, and we are using a single
>      entity, the structure generated by q2c, for both.  That's ugly.
>      Instead of making q2c better fit storage of settings, which is
>      not what it is designed to do, I'd much rather separate the two
>      purposes into two sets of code.  That is, add a settings.c and
>      set_*() functions that correspond with the existing get_*()
>      functions.  Then set.q just becomes a client of settings.[ch]: it
>      parses the option settings and passes them to set_*().  The GUI
>      can be another client.
>
> I agree that would be a better way of doing it, and I did think about
> that approach. My proposal however is a compromise which reuses  the
> existing code, and can (I think) be done in a lot less man-hours.

I don't see why it would take very long to reorganize this way.
I'd guess there's about an hour's worth of work in it.

Do you really think it's a lot of work?  Why?

> Are you happy for me have a go along the lines I suggested?  We can
> reserve the option to implement the set_*() method at a later date.

Any change to q2c can subtly screw up a lot of other code, and so
I'd prefer to limit changes to it to those that actually benefit
a lot of other code.  I don't think separating the structures
helps anything but this idea for set.q.

I'd rather not do it that way.
-- 
"[Modern] war is waged by each ruling group against its own subjects,
 and the object of the war is not to make or prevent conquests of territory,
 but to keep the structure of society intact."
--George Orwell, _1984_