On Wed, August 9, 2006 04:25, Aleksey Kontsevich wrote:
> And by the way I have a request here: could you implement empty
> constructor
> for pqxx::trigger:
> trigger() {};
> setName(string &N) {m_Name=N;};
> setConn(connection &C) {m_Conn=C; m_Conn.AddTrigger(this);};
> for convenience. Any way, 'trigger' begin to function only after
> m_Conn.AddTrigger function call, so I will able to make my own custom
> constructor and create Conn object within. Now I forced to make some
> external
> constructions and send previously formed connection object to trigger
> constructor, but I want to execute all my procedures within derived class
> and
> to reduce the code.
I'm not sure I understand what you mean here... Maybe you could show a
very brief example of the structure of your code?
If the change is really needed, I'll make it--but if there is a reasonable
way around it, I would prefer not to add these new functions.
Initializing objects with multiple method invocations like this introduces
opportunities for bugs: what if you accidentally call setName() on an
object that has already been setConn()'ed? What if you don't set a name?
What if you call setName() more than once before the setConn()? What if
you forget to call setConn()? What if you mistakenly passed a connection
and name to the constructur *and* called setName() and/or setConn()
afterwards?
And once we start going this way, it would seem reasonable to start doing
the same with connection objects, for example. It seems very convenient,
but the opportunity for mistakes and confusion is pretty big. With that
many variables, where do you make the transition from the object's
"setting parameters" phase to its "actual-use" phase where none of those
parameters can be changed? What parameters can you query during either
phase, and what answers do you get? I think that some of those would turn
out to be surprisingly difficult questions.
Then, I'd have to build checks for all those mistakes that people might
make, so programs don't "accidentally work" with one version of libpqxx
and fail with the next. I'd have to document what you can and cannot do.
And then you'd still have to test your program very thoroughly to see that
none of those tests failed. The advantage of the way things work now is
that the compiler will stop you from making any of these mistakes. It's
like different kinds of plugs and cables for power, USB, and so on: it
could be convenient in some ways to have just one type of cable and one
type of plug for all of these. But if plugs fit in lots of places where
they shouldn't be used, that would still end up making things more
difficult.
I know I am often pedantic in these matters--sometimes too pedantic. On
the other hand, I feel very strongly about "inviting" people to make more
mistakes. Testing is hard, and it's never complete. Everybody makes
mistakes, and the more mistakes are possible with libpqxx, the more people
will make them. Some of those mistakes make it back here as incorrect
libpqxx bug reports, and I hate telling those people "it's not a libpqxx
bug, you did it wrong because I made it so complex." I hate the thought
of failing applications that I may never hear about even more.
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
