[patch #6427] Syntax formatting utilities

[Ben Pfaff]

Follow-up Comment #6, patch #6427 (project pspp):

Thanks for the comments.  I'm posting a revised version now.

>1. Let's think of a better prefix. "gen_string" is so vague, it 
>could mean almost anything. How about syntax_fmt_* ? 

How about syntax_gen_*?  We have enough references to data "formats" already
without adding a new one.

>2. I predict that gen_string will almost always be called with 
>NULL as the second arg, so why bother with it? 

OK.  I deleted that argument.

>So let's split gen_string into 2 or 3 seperate functions, and make
>gen_string a wrapper around those 3.

Let's just use the single function for now, and if there's a good reason to
use a non-null argument we can invent a new function for later.

>3. In the comments for gen_string: "STR must be encoded ..." 
>What is STR? 

That's what I get for copying your comments without properly editing them. 
Fixed.

>4. > int quote; This could be bool ? 

Actually, no, the value of quote is used in the loop.

>5. In gen_pspp_valist, ...This will fail in the general case, 
>eg: "%3d".

That function is supposed to be specialized for generating PSPP syntax, and I
can envision little reason to want to create arbitrary field widths, etc.,
inside PSPP syntax.

I can forsee wanting to use a variety of different types in these format
strings, e.g. "%ld", "%zu", and so on.  But I'm not certain yet that these
functions are actually going to be useful enough to carefully implement all
these types yet.  I'm happy to implement them if needed later, just not before
it's demonstrably a good function in general.

>6. But at least let's make gen_pspp_valist accept "%%" in the 
>conventional fashion. 

Sure.  Fixed.

>7. In gen_{string, number, value etc} I suggest that we make the
> output string the first parameter rather than the last. 

OK.  Fixed.

>8. At the back of my mind, I have the idea that, in order to 
>properly cope with i18n issues, at some stage in the future, all
> syntax will have to internally be converted to wchar_t *. How 
>would this patch affect that decision if we took it? 

Possibly it could make it easier, because it would group much of the syntax
generation code into a single file would be easier to change than if it were
scattered throughout the source code.  I don't have any more detailed
predictions than that; I've never conducted such a transition before.

(file #15160)
    _______________________________________________________

Additional Item Attachment:

File name: format-syntax.patch            Size:22 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?6427>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/