-none- 2007-08-14 - By Graham Reitz
Back
Warren,
Wow man, there is no reason for this.
You're obviously upset about something other than 'just' my comments.
I hope that whatever is going on in your life improves. Something as
minor as this isn't worth getting this worked up over.
> Plain old criticism is "X sux." Constructive criticism is "X sux,
> but you can fix it with Y,"
I would politely disagree here. There is nothing wrong criticism by
itself. I think we would both agree that comments like, "Your
library sux," is completely inappropriate and definitely not
constructive, but that didn't happen here.
Kindly,
Graham
On Aug 14, 2007, at 5:11 PM, Warren Young wrote:
> 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.
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus?
> unsub=grahamreitz@(protected)
>
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=mysql@(protected)
|
|
