Skip to Content.
Sympa Menu

freetds - Re: [freetds] Header privatization

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Header privatization
  • Date: Tue, 23 Mar 2004 10:40:54 -0500

On Tue, 23 Mar 2004, "ZIGLIO, Frediano, VF-IT"
<Frediano.Ziglio AT vodafone.com> wrote:
> Yesterday I spent some time privatizing CTLib headers. The aim is to
> avoid implementation detail in headers so we can change implementation
> mantaining binary compatibility.

Sounds good, as long as they remain forward references, and don't become
opaque handles.

As you say, if the application uses the structures safely -- in the way
they're designed to be used, and in the way they're documented -- there's
no need to hide any implementation details. And, certainly, there's a
disadvantage: the data structures become harder to debug. Instead of a
pointer to a structure, you get an opaque handle that requires an arcane
cast to dereference.

In working with the ODBC library lately, I found its opacity both a
nuisance and a hinderance to working with the code.

I agree, a FreeTDS ct-lib program could choose to inspect the structure
rather than use a (safe) function call. But the structure is
superficially undocumented and subject to change. Anyone biting into that
bitter fruit is due for a taste of it.

As far as changing the headers goes, the other important thing to my mind
is to remove db-lib-isms. Each library has its own set of constants, and
it's to our advantage if, say, "success", with all its different names,
always resolves to the same constant. But there are definitely times in
libtds when we use a db-lib constant, and that can get in the way. And
there's no need for TDS constants in the sybdb.h.

> However this change can break some old
> compatibility. Application that access ctlib structures directly or use
> some tds functions simply can't work anymore (we never supported such
> implementations and always suggested to change coding style).

There might be some programs out there that use the structures directly
because the requistite macro or whatever didnt' exist at one time. I
doubt there are any such limitations left in ct-lib, so there's no need
anymore to dereference the structures directly ... except when debugging.


--jkl




Archive powered by MHonArc 2.6.24.

Top of Page