Paul Marquess said:
I assume your issue isn't really that I've used the same names as the C++
classes, but that I've put them in a top-level namespace?
Of course.
Ignoring namespace issues for a moment, reusing the C++ class names
seems to make perfect sense.
Well, yes... it depends on who's point of view your coming from. There
are rather different conventions for how things should be named in C++
and Perl (in particular, XML-related and DB-related modules in Perl
*always* spell them XML and DB rather than Xml and Db), so none of
those names would have been invented by someone writing a DBXML
library from scratch in Perl. If you are more concerned that someone
with familiarity with this library in C++ should not be lost when
using it in Perl, then stick to the C++ names. If you are more
concerned that someone used to Perl should not be confused when coming
to this module as a Perl module, with no knowledge of or interest in
the underlying C++ library, then more Perlish names would be better.
There is always a problem of clashing namespaces, and I accept that by using
quite a few top-level names I'm increasing that possibility.
The point of the CPAN namespace-registration system is that it gets
rid of the problem. People register their namespaces, and stay within
them, and then we don't get conflicts. You will note that the PAUSE
module-list registration form specifically says that you must provide
good reasons why you need a new top-level namespace.
I'm not convinced it's as big a problem as you make out,
Are you not? I think that as things stand there may not be much of a
problem, because 1. noone else would use those C++ish names and
2. everyone else will follow the rules and not use top-level names
when they don't need to. I don't think these are good things to rely
on.
As I said, consider someone using some other XML module: say, to get
XML out of their database and insert it into some other system. If the
name XmlDocument were considered fair game, you must admit it's not at
all unlikely that this other module author would have used it as
well. The only way there is any chance of avoiding clashes is if
everyone sticks within their own namespace.
but I'll have a think about this
one - my preferred choice would be to go for DbXml:: as the common prefix
for all the class names.
OK... it doesn't matter what you choose, as long as you choose something.
Ignoring the hoops I may have jumped through to implement my version of
"catch", from an end users point of view, that looks very like what I've
already implemented.
That was the point: it's almost identical, and doesn't stomp on about
6 top-level names.
One thing on my todo list is to provide a shortcut to get at the exception
string. I'll probably do it by overloading the stringification operator.
eval {
...
};
if (my $e = catch XmlException) {
print "got this exception $e\n";
}
Oh, does it not already?... I'd kinda assumed it would
.
Personally, I hate that syntax in user code, although it should
already work with my current interface.
Yeah, but it's (one of) the Perl idiom(s) for exception
catching. Someone reading that code will see instantly what it
does. Inventing random new interfaces violates the principle of least
surprise.
If I was going to go down that route, I'd rip out the exception handling
interface and use return codes instead.
Yup.... personally, I'd not object to that. Remember, people can
always put it back with use fatal. One of the things I dislike about
Java (I've never written any (modern) C++) is that everything has to
be wrapped in a try/catch block.
I think there are a couple of reasons for the difference in the interfaces
I created. The first is simply down to the fact that the native dbxml
interface is C++, while Berkeley DB is C.
....yes...? Neither is Perl, despite the superficial similarities
between C++'s and Perl's OO.
The other reason I've deliberately kept close to the C++ interface was to
future proof myself. The dbxml library is still quite young and has already
changed a couple of times -- I don't want to paint myself into any corner
with interface decisions.
This is, of course, sensible. Might I respectfully suggest a strategy
of having a DbXml::Native module that is just a very thin XS wrapper
around the C++ library, and then making DbXml implemented in Perl on
top of that?
Ben
