I've been thinking about the following related things:
- How to get rid of the _Inline/config file mess.
- How to support multiple implementations of the same language.
- How to support multiple glue layers in a single language.
- How to support different parsers in a language.
- How to make the Inline API more formal.
- How to make Inline more OO. Better inheritance.
- How to stay 90% backwards compatible.
Let me recap what the config file is all about. Its main purpose is to
determine which module to load when you do something like this:
use Inline '%$#@!';
Inline will look up '%$#@!' in the config file and say "Oh, that
language is supported by Inline::Fook". If the config file doesn't
exist, Inline launches a search mission to poll every module that looks
like an ILSM, and request meta-information from it.
Some of the reasons for this hack:
- To support:
use Inline 'C++';
Since Inline/C++.pm is not a legal module name.
- To allow multiple implementations of a language. If someone writes
Inline::Basic, but doesn't maintain it well, someone else can write
Inline::More::Basic and still allow the user to say:
use Inline Basic;
As long as the user doesn't have Inline::Basic installed, the
More::Basic module will become the "real" Basic.
- Allow performance optimizations like, "Don't load Inline::CPP if the
object has already been built and cached".
In hindsight, these things don't buy much. They were premature optimizations.
I think if a user wants Inline::Better::CPlusPlus, they should just say:
use Inline Better::CPlusPlus;
---
It seems to me that:
- All ILSMs should inherit from Inline.pm.
- ILSMs should be able to inherit from other ILSMs.
- There needs to be a container object (Mitchell calls this a "blackboard")
that contains all the state information.
- I'm not quite sure how the inheritance would work with it.
Here are a couple use cases:
- Mitchell Charity has written a faster regex based parser.
- He has also written a swig glue layer.
How do we expose these to the user without making them the default?
Here's some possibilities:
use Inline C => DATA =>
PARSER => 'regex';
use Inline C => DATA =>
GLUE => 'SWIG';
The defaults would be 'recdescent' and 'XS'.
Doing things this way requires the support of Inline::C. And it requires
defining an API for plugging in parsers and glue layers.
Another option is to let Mitchell write
Inline::C::Faster
and
Inline::C::SWIG
The interface could be:
use Inline C::Faster;
use Inline C::SWIG;
__END__
__C__
__C::SWIG__
So the syntax becomes
use Inline <language>::<flavor> ...
and the markers can be of either
__<language>__
or
__<language>::<flavor>__
Of course the flavors could inherit from the base language modules.
---
It's not clear to me which way to go. Do we want to create a lot of
independent Inline::C flavors that are more independent of Inline, or do we
want one Inline::C with pluggable backends?
I'm asking for suggestions or a show of hands here.
Cheers, Brian
