Re: commit -- first pass at command-line conversion


Subject: Re: commit -- first pass at command-line conversion
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 09 2000 - 14:09:32 CST


At 08:55 AM 3/9/00 -0500, Thomas Fletcher wrote:
>On Wed, 8 Mar 2000, Paul Rohr wrote:
>> 5. code factoring
>> ------------------
>> Finally, seeing all this redundant logic down in platform code makes me
>> itch. As always, suggestions for better refactoring of the code are
>> welcome. However, this shouldn't be done until #2 gets resolved.
>
>This was my concern when I put the changes into the QNX
>code. There was nothing there that seemed like it needed
>to be there.
>
>If nothing else perhaps we could have a
>
>preParseCommandLine() which could go throught and either
>set arguments to the function or member variables for
>showing the application and showing the splash screen.
>Also I would like to know again why it is that we have
>the parseCommandLine() code in the AP code ... I understand
>that X people might want -geometry and other X default
>command lines args to get processed, but it seems to
>me that there is still too much common code in there.
>
>Just something to consider if we are going to fix the
>issue with the translators, we might as well fix it
>for all of the command line parsing.
>
>Also the preParseCommandLine() function would be able
>to argument sanity checking and return a bool if
>it fails (which would allow us to limit just what
>sort of conversions we do as addressed by Paul).

Agreed. We already do *some* args parsing to create the XAP_Args class,
when it's called from platform code, so if we also pass in the
platform-specific nFirstArg on the constructor, that might help remove a
little bit of platform-specific code.

However, I think the major obstacle here is that some args are *app*
specific, but the app class factoring works as follows:

  AP_<os>App : XAP_<os>App : XAP_App

It's been a while since Jeff and I discussed this, but IIRC we both thought
it might be worth refactoring things a bit to add an AP_AppData class to
offload some app-specific work to XP code (a la AP_FrameData).

bottom line
-----------
If I could think of a solution that removed more code than it added, I'd be
very tempted to go for it. I admit that I haven't put much thought into it,
but so far nothing comes to mind.

Paul



This archive was generated by hypermail 2b25 : Thu Mar 09 2000 - 14:04:04 CST