posted by ![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
damerell at 08:51pm on 01/04/2009
damerell at 08:51pm on 01/04/2009Dear Lazyweb,
I'm writing a Perl program which I intend to have a curses interface. I've already written such a program, so that's not a problem.
However, this time it would be nice not to tie myself to _just_ curses, but to have the option of supporting other interfaces (SDL graphics tiles? libtcod?)
So what I want to do is to find out early on which interface the program is going to use (command-line option, config file, whatever) and then do something like loading an interface-specific module which contains a bunch of subroutines the main program can use, which have the same names regardless of the interface.
I suspect there is an existing idiom for this but I can't even think how to Google it. The approach that springs to mind is to "if (this) {require and import one module} elsif (that) {require and import another module}" and so forth but I really have no idea if that's sensible.
Any advice?
I'm writing a Perl program which I intend to have a curses interface. I've already written such a program, so that's not a problem.
However, this time it would be nice not to tie myself to _just_ curses, but to have the option of supporting other interfaces (SDL graphics tiles? libtcod?)
So what I want to do is to find out early on which interface the program is going to use (command-line option, config file, whatever) and then do something like loading an interface-specific module which contains a bunch of subroutines the main program can use, which have the same names regardless of the interface.
I suspect there is an existing idiom for this but I can't even think how to Google it. The approach that springs to mind is to "if (this) {require and import one module} elsif (that) {require and import another module}" and so forth but I really have no idea if that's sensible.
Any advice?
There are 9 comments on this entry.