On Mon, Nov 06, 2006 at 06:13:45PM -0800, Ammon Riley wrote:
> Hi Tim,
>
> > I'd be happy to allow "local_", "_", and perhaps "x_" to be used as
> > 'private use' prefixes that would never be registered to a driver.
>
> So to put this into an example, to make sure I understand correctly,
> if I had a function I wanted to make available automatically via
> install_method() -- say db::query_cache_report(), I'd name it with one
> of the above, and people could then automatically say:
>
> $dbh->_query_cache_report() # or
> $dbh->local_query_cache_report() # or
> $dbh->x_query_cache_report()
I was thinking your choice of prefix (pts) would be included:
$dbh->local_pts_query_cache_report() # or
$dbh->x_pts_query_cache_report()
(You're right that '_' isn't a good option.)
> I'm not 100% sure that I like any of those options, for a variety
> of reasons:
> 2) 'x_' is kind of meaningless, as far as prefixes go, and is completely
> arbitrary.
That's the point. It mirrors the role of 'X-' headers in email and mime
types etc (experimental and not officially registered).
You'd add your own tag after the x_, ie x_pts_.
> 3) 'local_' is not so bad, but I feel like it could limit the potential
> namespace of methods -- it's a word which has definite meanings,
> in a variety of contexts. For example, when I see 'local_', I
> automatically wonder if there is a 'remote_' counterpart method.
Local here means "I'm using a prefix I don't want to officially register
so it's only safe to use locally - I shouldn't release this code on CPAN".
> 4) There are several places in DBI::DBD that stress naming conventions,
> and choosing a prefix for private class data, etc. After doing that,
> and choosing a prefix of 'pts_', I find it odd to name methods I
> want to expose to the user with 'x_' or 'local_'.
local_pts_ (or x_pts_, which I prefer) seems quite reasonable, given
that you don't want to officially register.
> 5) As a user of the driver, it goes against everything I'd expect, in
> terms of naming, too. If I use, say Oracle, and am using
> DBD::Oracle, then I know any extra methods available start with a
> leading 'ora_' prefix. Consequently, I'd find it odd, when using
> this custom driver, to have to use a prefix of 'x_' or 'local_'
> for those extra methods, when 'pts_' is much more logical
> (particularly since the driver is DBD::PTSProxy).
It may seem 'odd', but you can't have it both ways. The namespace is
managed specifically to avoid the risk of two developers picking the
same name. A registered name has value. An unregistered same should be
clearly unregistered. Either you register the name you want or you put
up with the minor inconvenience of an extra prefix.
> What if, rather than simply blocking off an arbitrary prefix to DBD::
> developers, there were a mechanism to allow us to specify what our
> prefix is?
Sorry, but I don't want to go that way.
> The downside, of course, is the danger of a prefix collision with
> a database driver which gets registered officially in DBI at a later
> date. I don't think this is really a big issue, since it appears
> (according to a quick grep of DBI.pm, anyway) that the registry is
> only used in install_method(), and if the prefix already exists, I
> can just delete the call to register_prefix().
Ignore install_method and think about method attributes. For example:
$sth->bind_param(1, $value, {
ora_type => 97,
ix_type => 42,
syb_type => 82,
pts_type => 13,
}
If you don't want to register the driver then using x_pts_ as a prefix
doesn't seem like much of a burden.
Tim.
