> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Jueves 1 de Junio de 2000 9:48
>

[Connections v/s txns]

> You would need two Connection objects. If the second were created by
> Connection::clone(), there would be only one database attachment. In
> my implementation, there are no limits.

Ah, it's a limitation from the pov of the interface. If you do that
optimization internally with clone(), then I do not have more observations.

> Properties (abstract replacement for Parameters) is used only to pass
> an arbitrary and open ended set of named values on the openDatabase
> and createDatabase calls, and is not really part of the object model.

An important point I missed in the first review. Then better as they are.

> Your point about making the method names parallel to PreparedStatement
> is well taken. I chose to use "put" rather than "set" since there can
> be multiple values.

Thanks. While less names I have to remember, easier is the life.

> >- As I see things, the only way to set Parameters' values is
> through strings
> >in the putValue functions, is this the ODBC way? Is this practical?
> >
> Yes, but I think this is appropriate for the extremely limited use
> of Parameters/Properties.

Well, if Parameters have one only function and meaning as SQL tokens, then
no problem.

> >- Why do all PreparedStatement.setXXX functions take an index?
> Probably it's
> >fast, by a field name would be clearer in several cases.
>
> The PreparedStatement::setXXX guys are used to set values for parameter
> markers ("?"), which don't have names.

This is the common level denominator, I guess, because the engines seem to
use all of them the "?" to mark parameters. However, I'm trying to simplify
the case of the same parameter appearing more than one time, a simple
setting by name could help life a bit. One starts to get used to high level
components hat use names... even if the "?" is the symbol used internally by
the engine.

> >- What's ResultList and how is it used?
> Output of a full text search. InterBase doesn't support it.

Maybe an UDF?


[About exceptions]

> I've had trouble with MSVC++ throwing localing object instances that
> I've never particularly run down.

I've had trouble trying to write standard C++ with full exception
specification in MSVC++, so no surprise here.

> It is certainly simpler to throw
> an object that doesn't need to be explicitly deleted. I want to
> replace the SQLException class with an abstract class of the same
> name, so this is a good time to revisit the question.

Ok, let's try to revisit it. The problem is I don't know how well a
solution scales to Linux and shared libraries, for example, this is where
your experience counts.

> That said, assuming an class has a virtual destructor, the delete
> operator is library/program safe.

Yes, it will find always the correct destructor, but hopefully better if
the virtual tables in the library and the program are in sync. :-)

> Now maybe if we eliminated
> the delete operator in favor of garbage collection,

Then you are speaking about safe C++, known also as A++ I believe. Or we
can have another peek at Objective-C, that runs as a preprocessor. Or we can
switch to Eiffel and have the garbage collector being enabled/disabled at
will... or we can create a SQL-like language to satisfy your needs to avoid
confusion in the reuse of the same reserved words (in that case, we better
go back to GDML).

> eliminated
> non-virtual methods,

Because all methods are virtual by definition, implicitly like Smalltalk?

> dropped overloaded operators as confusing,

I can't agree here even if you send me a check. I like too much name
overloading and operator overloading even if you prefer the only-one-meaning
of SQL. Simply put, procedural and OO languages don't have to be so
castrated as declarative languages.... IMHO of course.

> purge "union" as unsafe,

Ah, well, union is only required in very specific code and probably best
avoided or encapsulated deeply in a class implementation. I almost thought
you were speaking about SQL's UNION.

> and required all method to find a home
> in a class namespace, we could improve the language... C+=2?
> Hot Chocolate?
> Jim Starkey

Don't try to fool us, Jim, you are speaking about Java and no other thing.
Let's call Jim++ to avoid further discussions about languages... as you need
time to understand Bill's passion for XML, I need time to understand your
passion for Java.

C.