Brian Aker wrote:
Hi!
In the process of going through our interfaces, one thing I am thinking
we should do is ditch the multiple val_*() in favor of a single method,
probably get(), which instead of returning a value will just pass in a
reference that we will populate. Main reason for this? I believe this
would make the current interface a little more bullet proof then what we
have now. If I had my druthers I would love to find a consistent manner
to determine if the conversion was illegal as well.
This is a good idea, and I dealt with some of this inconsistency while
doing the temporal work. It's tricky at best.
> We inherit this bad
behavior, I would love to start fixing it. There are three things I
typically care about:
isNull()
isConversionError()
Off the top of my head we could do either:
bool get(int32_t& value, bool& is_null);
bool get(int32_t& value, bool& illegal_conversion);
In the above the first method would return state would determine if an
illegal conversion occurred or not. In the second we would handle NULL
case via return, and for conversion we would pass reference. The only
advantage I can see with having one over the other, is that the second
method we could adopt and slowly fix/add errors for illegal conversion
(something I would love for us to do, I dislike this particular "gotcha").
The above is essentially the interface in Temporal and its subclasses,
however, there are some of the problems you will run into.
For instance, how do you do this portably?
bool get(int32_t &value, bool &is_null);
bool get(uint32_t &value, bool &is_null);
I think you will run into problems with compilers across different
platforms. I know I did, and that's why there are methods like
to_int64_t() and to_uint64_t()...
Secondly, I think a cleaner overall solution is one of the following:
1) Use exceptions properly. throw a BoundsException or similar when
conversion doesn't succeed. This is the "C++" way...
2) If we want to continue to not use exceptions, do the STL thing and
have a fail() method which returns false if the last operation did not
succceed, and have a getErrorCode() and getErrorMessage() method which
enables callers to query the object for its error information.
<snip>
On a general note, I mentioned to Monty Taylor that we should be making
sure any new code is using references and const as much as possible. I
am cleaning up some of the engine interface around this right now and
doing this. In general we should be doing this where ever we can. From
watching bug reports, these two simple things would save us a lot of
headaches.
Agreed. Use pointers when supplied parameters may be NULL or when you
are indicating to the called function that it is responsible for
directly manipulating memory, references otherwise...
-jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
