Skip to Content.
Sympa Menu

freetds - Re: [freetds] [ freetds-Patches-1064459 ] new app program - datacopy

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: brian AT bruns.com, FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Cc:
  • Subject: Re: [freetds] [ freetds-Patches-1064459 ] new app program - datacopy
  • Date: Thu, 2 Jun 2005 00:21:18 -0400

Brian Bruns wrote:
> Jim,
>
> It's not that I think it shouldn't be there, I believe it is a fine
> additon to the library. I want to make sure this issue gets a proper
> airing before we commit to a name. Changes to the .so version not
> withstanding, it'll be a pain to change it later, and more to the
> point it's a precedence thing.

OK, no problem and no rush. :-) I agree it should be thunk over. I've
even been known to change my mind, once in a blue moon.

> I believe this guy should stick out like a sore thumb. When looking
> at the code, or copying from somewhere else anyone should immediate
> say "ah that's not a portable function". We already have the tds_*
> namespace for our own functions. Problem is the name is a bit
> unwieldy to begin with so tds_dbtablecolinfo() is even worse. ;-)
> Perhaps something shorter like tds_dbtabinfo() ??? Opinions?

I think the name is good as is, apart from being a mouthful. I haven't
looked closely enough at the functionality yet to have an opinion on that.


Portability? I look at is this way:

nTotal Both Microsoft Sybase
----------- ----------- ----------- -----------
274 142 41 91

That is, of the 274 total functions described by the vendors, something
like half are implemented by both. Looked at another way, the odds of a
random db-lib function being portable are 50:50. dbtablecolinfo() doesn't
affect the balance very much.

I very much do not think tds_ is a good prefix for a db-lib function.
That, I think is misleading. Yes, all functions so-named were written
here, but OTOH should be treated as volatile conveniences. Our contract
is with the published APIs.

If you came across dbtablecolinfo(), you wouldn't recognize it. You'd
almost certainly look it up, wouldn't you? If you consulted our very own
reference manual, you'd find it there, marked as a FreeTDS function.

Honestly, I can't think of a better prefix than 'db'. 'DB', for example,
would enter another namespace. 'tdsdb' is OK, I suppose; we have
tdsdbopen() already. But for the reasons stated I think the choice Bill
made is actually the best one.

Is any of that at all persuasive?

Regards,

--jkl

> As we accumulate more of these over time (not sure how likely that is
> really, but...) we should adopt some kind of convention and follow it.
>
> Cheers,
>
> Brian
>
> 2005/5/31, James K. Lowden <jklowden AT freetds.org>:
> > Brian Bruns wrote:
> > > I know we had a big discussion about the name "dbtablecolinfo" and
> > > namespace pollution in dblib. What was the resolution on this? I
> > > for one would prefer to clearly delineate this as a FreeTDS only
> > > function.
> >
> > Hi Brian,
> >
> > I believe Nick raised the concern of "polluting" the namespace.
> >
> > My feeling is that FreeTDS is a set of libraries that conform to the
> > specifications and/or behaviors of the vendors' offerings. As long as
> > we do that, there's nothing wrong with adding functions that make our
> > version more convenient or efficient. Ours is an open source project,
> > after all, making it extremely easy for anyone so inclined to remove
> > our "extra" functions. And, in the event we actually trip over
> > something that's widely inconvenient -- a la dbopen() -- we can always
> > change the symbol's name and bump the .so version.
> >
> > By that reasoning, I think dbtablecolinfo() is a fine addition to the
> > db-lib namespace. Anyone writing db-lib programs and naming his own
> > functions dbanything() is playing with fire anyway; anyone reading
> > application code would automatically assume dbsomething() is a db-lib
> > function.
> >
> > As for documentation, aye. Bill's innovation would require a new
> > column in api_status.txt, if we want to include it. (I think we
> > don't.) It already has a doxygen comment block that clearly denotes
> > it's a FreeTDS-only function.
> >
> > But I don't mean to shout anyone down. If I'm missing something, I'm
> > sure you or someone else will tell me. :-)
> >
> > Regards,
> >
> > --jkl
> >
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page