NOTE: This is from an offline thread with Mitchell that I am forwarding with
his permission.
On 06/10/02 19:15 -0400, Mitchell N Charity wrote:
> Hi Brian,
>
> Wow, lots of things happening with Inline.
> Awesome.
Yes. It is pretty cool. Inline is exciting for me again. Last year it was
YAML. But I have enough people to carry that along for a while. And YAML is
only 1/3rd my ideas. This is Inline part two. Inline gets serious. Well,
hopefully.
> A couple of thoughts:
>
> GLUE vs PARSER vs WRAPPER --
>
> A possible set of definitions is
>
> PARSER takes code to types. There are two existing examples, the
> recdescent and regexp-based versions.
>
> WRAPPER takes types and generates stubs. There is the current XS
> based version, and the proposed non-XS version you mentioned.
>
> GLUE takes code and generates stubs.
PREPROCESSOR or FILTER is another possible step.
>
> Two complications:
>
> The non-XS wrapper will probably also be messing with the build
> details (no Makefile.PL, etc). So it might need a {BUILD} var to
> alter.
>
> One might perhaps get by with only a "ui simple" GLUE => mumble
> flag, if one could specify multiple GLUE's, and Inline could figure
> out what was being asked for. If can($glue_argument,'compile') etc.
> The upside of this complication is that the UI is smaller (1 flag
> vs 3), and perhaps more easily extensible (if we need to add more
> than the 3). Perhaps a general VARIANT mechanism?
I like a multiple inheritance mechanism like OVERRIDES. One keyword
specifying one or more classes to inherit the various parts from. And I
like keeping it all one directory below the Language Module. Example:
use Inline C => DATA =>
OVERRIDES => [ParserRegexp, GlueSwig];
This would of course inherit methods from:
Inline::C::ParserRegexp
Inline::C::GlueSwig
Inline::C::GlueDefault
in that order. GlueDefault would contain all the default methods.
Any variant module would contain one or more overrides. This would
scale nicely.
> Installing swig via CPAN --
>
> My initial reaction is "Please no". :)
>
> I don't know of any CPAN packages which take this approach, and many
> which take the much simpler "if you try to install the module, but
> the underlying libraries/programs are not available, then fail and
> suggest they be installed".
>
> I think simplicity should trump making it easier for folks to play
> with substituting SWIG for the standard Inline parser/stubbers.
>
> At least in the near term.
> It's not like there isn't lots of other stuff to do.
>
> No?
No! This is my initial reaction. :-)
I can count on zero hands how many CPAN modules use SWIG. SWIG will
never make any impact on the CPAN unless it can be installed as a
prerequisite module. Some modules require non CPAN components, like
XML::Parser. That's justified because, "What else are you going to do?".
But SWIG is just a glue layer and XS is available on every Perl
installation. To build over SWIG would be the kiss of death.
But if SWIG were just a module prereq, it might have a fighting chance.
I suppose we'd have to coordinate with Dave Beazley. I'm pretty good at
creating CPAN software distributions that don't just contain Perl
modules. I think putting SWIG on CPAN is doable. We should at least
give it a try.
> Naming parsers --
>
> One possibility to bear in mind is a naming convention without
> subdirectories. Something like
> Inline::C::ParseRecDecent.pm
> Inline::C::ParseRegex.pm
> rather than
> Inline::C::Parse::RecDecent.pm
>
> The possible advantage being that parsers may be a best-case in
> terms of clean-ness of partitioning. Other modules may be messier
> mixes of tasks. If there is a Inline::C::Parse directory, and an
> Inline::C::Wrap, etc, where does one put modules which do more than
> one of these?
+1 Good idea. I think this is coming together. Can you think of a better
keyword than OVERRIDES or VARIANTS?
Cheers, Brian
