Darren:
On Fri, Aug 14, 2009 at 3:06 PM, Darren Duncan wrote:
> Another reason for the X convention is about reputation and credit, like
> with trademarks. The reason is for being able to distinguish at a glance
> between official components made by or endorsed by the creators of the core
> proje
On Fri, Aug 14, 2009 at 09:52:37PM +1000, Adam Kennedy wrote:
> Now that we've got a number of integration points available for
> feeding code into SQLite's internals, I'm wondering if we should
> consider some form of blessed or recommended namespace for people to
> write these extensions in.
>
>
Another reason for the X convention is about reputation and credit, like with
trademarks. The reason is for being able to distinguish at a glance between
official components made by or endorsed by the creators of the core project,
from those by third parties that are not endorsed; by default, e
The main reason for the X system is "A giant project that might
potentially use all sorts of different names wants full control of
this namespace, so don't trample on anything that might be a problem
later."
That isn't really the case here, the of all the different options
SQLiteX can probably be
I would vote for "SQLite::" ; the fact that there are already some modules in
that namespace does not prevent people from creating new modules; on the
contrary.
The DBD::SQLite:: namespace is specific for the driver, so I wouldn't recommend
using that one.
Finally, one could think of "SQLiteX:
As there're already several applications in the SQLite:: namespace,
it might be better to use (DBD::?)SQLite::Extension:: for the ones
to be loaded via load_extension(), and (DBD::?)SQLite::Module::
(or whatever) for the ones that adds a customized callback etc.
Kenichi
On Fri, 14 Aug 2009 21:52:
Now that we've got a number of integration points available for
feeding code into SQLite's internals, I'm wondering if we should
consider some form of blessed or recommended namespace for people to
write these extensions in.
Are we just going to recommend SQLite:: or does anyone have alternatives?
As a Makefile.PL, we aren't really supposed to be able to know how DBI
is implemented, or how it got there. We're just asking for the API.
I agree with the compiler feature point though, the errors we're
getting are mostly about no cc command at all.
Maybe we can just pull something similar to Mo
Hi.
1) We can rather easily see if a compiler exists or not, but
I think it too much to test if the compiler has some feature
or not. And, as DBI we require also requires a working compiler,
(false) unknown is not so bad (why do they have DBI when they
don't have a compiler? - probably they instal
