Graham Reitz wrote:
>
> I also stated mysql++ has many very nice features.
What's wanted here isn't more praise, but more ideas.
> 1) Macros are very difficult to debug.
Yes, that's well understood. If you'll read the Wishlist, you'll see
that the proposed SSQLS replacement already addresses this.
> I had to go through a ssqls 50 columns in length and eliminate each
> column one by one to figure out what the offending type was.
Learn binary search, love binary search.
> Compile time errors are always more desirable than segmentation faults.
None of what I wrote was related to your uninitialized variable segfault
issue. That's a pure bug report, and is totally fine.
We're talking about design errors here, not plain ol' bugs. The
distinction is this: if fixing it requires changing an interface, it's a
design error. I can fix this problem inside the ColData class itself.
It's just a bug.
> If blob types need to be initialized ahead of time the compiler should
> indicate that requirement, not a seg. fault.
No, a default-initialized ColData should have reasonable defaults, so
when you access it, it doesn't blow up on you.
> 2) It is common to have tables > 50 columns in length.
Sigh...proof by assertion.
The question was, "what kind of design requires this?" The only way you
can answer that to my satisfaction is to show me your schema, and defend
it. If you're not willing to do that, that's fine. I will just go on
believing that it's probably wrong, due to lack of evidence to the contrary.
> 3) The need to use the MYSQLPP_SSQLS_NO_STATICS macro is undesirable
....and you would do what instead?
> 4) Using namespaces to workaround an issue with auto increment fields
You must not have understood my reply to Jim, or didn't read it. Go
read it [again].
It tells you that you can have two SSQLSes in the same namespace for the
same table, with different C++ structure names.
> 5) Exceptions might be overused, depending upon the author's definition
> of what is an exceptional circumstance.
You're acknowledging that this is a taste issue, so the only change that
can satisfy more than just yourself would be something like a pluggable
exception policy framework. And if that's the solution, I have only one
response: patches thoughtfully considered.
> Any library even the c++ standard libraries should be able to and eager
> to receive criticism from time to time. It is not a personal attack in
> any sense. I am sorry if it seemed that way.
No, actually, plain old criticism never receives a warm welcome, not
anywhere, from anyone. This fact of human interaction is so basic that
most people figure it out before they leave elementary school.
What is welcome is *constructive* criticism.
Plain old criticism is "X sux." Constructive criticism is "X sux, but
you can fix it with Y," where Y is more than just a buzzword. In the
context of MySQL++, Y needs to be an actual design, if not a code patch.
The closest thing to constructive criticism you've offered so far
amounted to "fix it with RAII". This is about as helpful as answering
"wash more often and stop copulating" when asked what to do about the
African health crisis.
If you want to be helpful, you're going to have to offer more than just
vague prescriptions.
