Re: [code-review] considerations with modular XS and short namespaces

On Mon, Mar 01, 2004 at 03:48:46PM +0000 Adrian Howard wrote:

> On 1 Mar 2004, at 10:27, Tassilo von Parseval wrote:
> [snip]
> >Ideally, I'd release a Device::CDROM that only provides those things
> >common to all platforms (like the various addressing modes, track 
> >layout
> >etc of a CDROM drive) and encapsulate the platform specific things in
> >other modules (such as Device::CDROM::Solaris) that need to be obtained
> >separately from the CPAN. The actual methods (e.g.
> >Device::CDROM::read_audio and all the others) become abstract methods.
> [snip]
> 
> This sounds very much like the same problem faced with DBI (database 
> independant API + database specific optional functions). You might want 
> to consider a similar DBI/DBD type distinction.

This is probably the most reasonable answer. I also thought of this
DBI/DBD model but put it back onto the stack as it requires some
preliminary interface considerations (and I hate those).

Another idea I might have to abandon is staying completely inside XS. So
far the only non-XS part was the autoloader for the various constants
#defined by the header.

Anyway, I'll start right away with all that. Once I have the base module
and at least one driver backend (most likely the Linux one), I'll ask
this group again for some feedback.

Tassilo
-- 
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval