Jochen Stenzel [10/12/01 01:04 +0100]:
> My point here is that I had to duplicate Inline::C code in
> Inline::Yacc. It basically worked, but for future releases (and more
> subclassing Inline:: modules) I ask for an interface which allows to
> include additional "preparation" steps as described, without having to
> copy parts from the parent module (which might be(come) subject to
> changes).

It isn't documented, but we've definitely broken down the API inside
Inline::C quite a lot, so that Inline::CPP can use it. Here's a tree view of
the methods in Inline::C:

build
  |__ parse
  |  |__ get_maps
  |  |__ get_types
  |  |__ filter
  |  \__ get_parser
  |
  |__ write_XS
  |  |__ xs_code (if XS_MODE is enabled)
  |  \__ xs_generate (otherwise)
  |     |__ xs_includes
  |     |__ xs_struct_macros
  |     |__ xs_code
  |     |__ xs_bindings
  |     \__ xs_boot
  |
  |__ write_Inline_headers
  |__ write_Makefile_PL
  \__ compile

Inline::CPP overloads only 3 of these build steps:
 - Inline::CPP::get_parser() creates a C++ parser, not a C parser.
 - Inline::CPP::xs_generate() generates a typemap, then continues with
   its parent's xs_generate by calling SUPER::xs_generate.
 - Inline::CPP::xs_bindings() writes out XS bindings for all recognized
   functions in the C++ code.

All the other parts of the build process are inherited from Inline::C.

> This interface could possibly be cascaded and therefore made be
> general. For example, there
> might be another Inline::XY which wants to produce yacc code from
> something inlined and therefore could be implemented as an Inline::Yacc
> subclass to reuse existing code. (Even if this is not really  probable,
> you get the cascading idea ...)

I think what we really need is documentation. We have lots of documentation
for users, but not that much for developers.  Basically, Inline::C needs to
document the tree-of-methods structure I drew so that Inline::Yacc writers
can take advantage of it. 

More generally, every module author should probably do the same thing,
especially if you're writing a module which is likely to be subclassed.
Inline::Basic might be a good example (but I don't know for sure).

Later,
Neil

Reply via email to