Interface should be determined at compile time

[NIIBE Yutaka]

Alex Shinn wrote:
 > I can think of plenty of reasons you'd want to determine modules
 > dynamically at run time.  Consider a general database interface, like
 > Perl's DBI, which can choose between different database backends
 > depending on what you have installed.  Or modules which check if you
 > have certain features/libraries installed and take advantage of those,
 > substituting stub definitions otherwise.  One idea I've been kicking
 > around (much more complicated than the database example), is a
 > universal graphical interface module, which would try to present the
 > same data through either GTK, ncurses, or whatever native interface
 > you have.

Good point.  Thanks for good and concrete examples.  I think that it
is good thing for users to choose _implementation_ of modules
dynamically at run time.  I agree.

 > Of course, this makes compiler optimizations much more difficult.  But
 > would it be too much to allow run-time lookup of modules, and only
 > optimize on what's known at compile time?  Maybe in the future
 > figuring out a way to optimize a "module chooser" with pre-defined
 > symbol names.

It's not just an optimization issue or compiler issue.  It is the
_interface_ issue.  If the interface is determined at compile time (or
development time), we can check the correctness of calls or the
consistency of usage of the module.  Provided the interface is
matched, users are free to load any implementation at run time.

I (rather strongly) believe that the interface should be determined at
compile (development) time.  The interface could come with runtime
enhancement feature such as OOPS, but still basic interface is
determined at comile time.
--