List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:August 16 2007 8:11am
Subject:Re: SSQLSv2 design discussion
View as plain text  
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.


> 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.
SSQLSv2 design discussionWarren Young15 Aug
  • Re: SSQLSv2 design discussionChris Frey15 Aug
    • Re: SSQLSv2 design discussionWarren Young16 Aug
      • Re: SSQLSv2 design discussionChris Frey16 Aug
  • RE: SSQLSv2 design discussionJoel Fielder15 Aug
    • RE: SSQLSv2 design discussionJoel Fielder15 Aug
      • Re: SSQLSv2 design discussionWarren Young16 Aug
        • RE: SSQLSv2 design discussionJoel Fielder17 Aug
    • Re: SSQLSv2 design discussionWarren Young16 Aug