Re: set.q

[John Darrington]

On Tue, Dec 06, 2005 at 04:13:44PM -0800, Ben Pfaff wrote:
     
     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'm not so sure that it wouldn't benefit other code.  When I was
implementing ONEWAY and EXAMINE , I really wanted to put the output
routines in a separate module.  But I couldn't.  Everything had to go
in a single *.q file because that was the scope the cmd_* struct.  My
proposal would  at least allow the data which pertains to the
definition of the command and the temporary data used in parsing the
command to have separate scope and separate modules.

Also, thinking ahead to if and when we implement a client-server PSPP,
it may be desireable to pass the definition of a command (say struct
defn_oneway) from the client to the server --- the server is not
interested how that command was parsed, it just wants to know what to do.


     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?

It'd be an hour's work if I simply define every subcommand as
'custom', and have the custom_* function call the set_* function.  
But then we'd loose all the range checking etc. that set.q
currently gives us (things like boxstring=string "x==3 || x==11" "3 or
11 characters long" would have to be explicitly implemented).  It
would also preclude any possibility of implementing intelligent
command line completion for subcommands.  Re-implementing and testing
all these sanity checks would take a lot more than an hour. Or can you
think of another way of doing it? 


Anyway if you really want to go down the 'custom' path I can do that.
But I think there's merit in separating the descriptions of commands
from their parsers (I'd like to be able to free the parser data as
soon as the parser has completed). Perhaps you can think it over for a
bit. 


J'
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

pgpV2VCmRRive.pgp
Description: PGP signature