Re: TDBC documentation, examples, syntax?

On Feb 20, 9:59 pm, Kevin Kenny <kenn...@xxxxxxx> wrote:
is needlessly inflammatory, and seriously tempts me to do the
opposite of anything you suggest, merely out of spite.

Yes, you are right. Needlessly inflammatory is a pretty valid
description of most of my comments.

So let me back up and start over.

First, working code is always superior to theory, nobody can argue
against something which works.

OTHO, there is a lot of working code based upon standards or
conventions, and in particular ISO/IEC 9075. This standard is long,
thousands of pages. But this fact contrasts with the "call to arms"
statement in TIP 308:

"If we look at other database connectivity layers such as ODBC/DAO,
JDBC, Perl's DBD/DBI, we find that there really isn't very much, if
anything, inside them. Rather than being a body of code, they consist
primarily of specifications of the interfaces to which the author of a
database connectivity module must conform."

It seems obvious to me that an interface would not contain a body of
code, but ISO 9075 contains more than an interface, it defines an SQL
environment. The standard isn't code, but rather a long list of
algorithms. When you produce code which conforms to the algorithms,
you meet the standard.

Database vendors should try to follow this standard. But the standard
is huge, probably no vendor complies exactly with the standard. So
full compliance is really unimportant.

What is important is "reflection". This is different from the OO
reflection, since there is no dynamic component. Rather, reflection
means that a higher (closer to the end user) layer strives to
"reflect" the lower layer...as much as possible.

The simplest type of reflection is "pass through semantics". With pass
through semantics, function names remain the same and argument order
remains the same.

If you just change the function name, while the signature remains the
same, you can use a "mapping".

What I see in the TDBC API is a distinct, un-mapped API. This does not
mean that the API is defective, it just means that programmers who are
familiar with ISO-9075 will struggle to map the TDBC API to the
corresponding ISO-9075 API. If the mapping is not one-to-one, it
should be necessary to ask if the underlying semantics are the same.
If the semantics cannot be proven equivalent, the application can't be
guaranteed to produce the same results.

The real core problem with TDBC really has nothing to do with the "top
layer API", this is what we see as we write Tcl programs. The problem
is the "completely undefined mapping" of this top layer to the
specific API. Whenever TDBC uses special names and conventions, expert
users get screwed.

Is there some mapping from Tcl to "some undefined data manager"?

Anyway, get a clue: any layer code needs two interfaces (one up, one
down). At most I see one semi-explicit upper interface and one non-
explicit lower interface.

Lots of flesh is needed.
.

Relevant Pages

  • Re: TDBC documentation, examples, syntax?
    ... base standard. ... There is no "abstraction" in your API. ... TIP 308 is irrational and unrelated to current database interface ...
    (comp.lang.tcl)
  • Re: The biggest mistake in classical optics
    ... interface boundary conditions imply a surface layer at least a few ... I'm not sure exactly what standard approach is being described ... relies on fixing fields and their gradients at the interface. ... Thus you might not need an assumption of wavelengths, ...
    (sci.physics.electromag)
  • Re: C API??
    ... >I assume API means Application Programming Interface, that is, the standard ... Note the word "interface". ... an API makes the term pointless. ...
    (comp.lang.c)
  • Re: For the AdaOS folks
    ... API that says create/delete an integer? ... >>as an Ada binding, I can do another registry query and get the ... libraries can strengthen the typing of the Ada interface. ...
    (comp.lang.ada)
  • Re: A C++ Whishlist
    ... > not a reasonable thing to expect from the standard library. ... of the ECMA Script standard you will learn that complexity doesn't stop ... > The simple separation of interface and implementation that header files ...
    (comp.lang.cpp)