Chris Frey wrote:
>
>> option use_accessors getX
>
> ...Capitalization of the X could be significant:
That was the idea, yes.
>> The "option" statements let you control naming scheme details. By
>> default it will output code in a style close to that used within
>> MySQL++; if we have to pick a default, it might as well be that. But I
>> realize this is not the worldwide standard, so wherever possible it
>> should give you the option to change its output code style.
>
> If I understand what you mean by style, this seems like a lot of work
> for nothing. Nobody should care what indentation is used in a file
> full of generated code.
It would indeed be foolish to try to try to support options for multiple
whitespace rule sets. If someone is so anal they need their special
brace and indent style in *generated* code, too, they can postprocess
ssqlsxlat's output with a code reformatting tool.
> What does matter (and perhaps you were thinking of this all along)
> is the interface, and how the programmer calls it.
Yes.
> This brought an interesting idea to mind though: would there be any
> use in putting actual C++ code in the .ssqls file,
Can't say that interests me. You can add code to a generated SSQLS by
deriving from it. These should make fine base classes.
> I'm not really here. :-)
Are you ceding nominal control of the packarray project, then? I mean,
if someone were to just take over and finish it, would you object?
> Where does portable database support stand, btw?
4.0 or later, that's all I can say at this point. 3.0 will be big
enough already.
> Is it any easier to implement now than it was before?
I doubt there's any appreciable difference.
