> The following was supposedly scribed by
> darren chamberlain
> on Wednesday 21 January 2004 11:10 am:
>* Eric Wilhelm <ewilhelm at sbcglobal.net> [2004/01/21 10:58]:
>> I'm trying to find a good way for CAD::Drawing::IO to determine which
>> of the CAD::Drawing::IO::* modules are available.
>
>It sounds like what you want is to ensure that the IO::* modules are
>polymorphic, i.e., to ensure that they all adhere to the same interface.
>Then, like DBI, CAD::Drawing::IO can be setup to load the appropriate
>implementation module (no groveling in @INC, that's what require is
>for), instantiate an object, and then call the appropriate methods on
>that object.
Not exactly. The IO::* modules do not have constructors, and neither does
IO.pm. Maybe "mix-in" is the wrong term. Essentially, every function is
inherited *by* CAD::Drawing, so basically, the entire set could simply be in
the one package and file, but that's a lot of code. Maybe they are more like
"add-on" packages? Functions from IO::* modules are inherited by IO.pm,
which is inherited by Drawing.pm, so with $d = CAD::Drawing->new(), you could
call $d->loaddwg("file.dwg", {}), but you are better served by
$d->load("file.dwg") where load() is actually CAD::Drawing::IO::load() and
loaddwg() is CAD::Drawing::IO::OpenDWG::loaddwg().
>Your main module (IO.pm) shouldn't need to have knowledge
>of the various IO::* modules.
It needs to have some knowledge of them in order to redirect the action
request to handle the particular filetype. Also, I'm not sure that
polymorphism is really helpful, since IO.pm is always getting a CAD::Drawing
object, it is not like it has a classed object which will automagically go to
the correct class for its method. With the current setup, the IO::* modules
are really just packages.
So, I guess my challenge is how to make IO.pm find all of the qualified,
installed packages under CAD/Drawing/IO/*.pm and call the correct function
based on either the explicit filetype or extension which is received by
load() or save(). I can see doing this with a foreach() / require() / eval()
setup or something where the packages contain code refs, but that doesn't
seem very tidy, and with some Inline-based modules as backends, I'd like to
have as much as possible happen at compile time so that C/XS errors are
thrown at the beginning instead of the end.
The primary goal is to make the module more easily installable (and possibly
to eventually pass the CPAN autotesting), but I'd also like other authors to
be able to write IO::* modules (for other geometric formats) without having
to add code to IO.pm or make changes to your main program (e.g. if you give
the program an argument of "output.igs" and an iges format save function is
available, it just "does the right thing".) With this model, your main
program would not have "use CAD::Drawing::IO::IGES;", but simply "use
CAD::Drawing;".
Thanks,
Eric
