On 05/10/02 13:43 +0200, nadim wrote:
> On Friday 04 October 2002 09:04, Brian Ingerson wrote:
> > I've been thinking about the following related things:
> >
> > - 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.
>
> Brian wrote:
> > defining an API for plugging in parsers and glue layers.
> > Inline::C::Faster and Inline::C::SWIG
>
> Like Nicholas, I like the setup in some sort of config file. The problem
> with Inline::C::Faster is that one doesn't know (by only reading the name)
> if it is another implementation, another parser or another glue layer.
OK Makes sense. For now I'll support:
use Inline <lang> => <source> =>
PARSER => <parser-name>
GLUE => <glue-name>;
In Inline-0.44, I'll have two options for PARSER:
- recdescent
- regexp
They will be implemented by the modules:
- Inline::C::recdescent
- Inline::C::regexp
And they will support the methods new() and parse().
Maybe they should be:
- Inline::C::parser::recdescent
- Inline::C::parser::regexp
And they could inherit from Inline::C::parser. And i could have an
Inline::C::glue base class.
The nice thing about this approach, is that others would have an API for
writing their own parsers and glue layers without needing my help or
permission.
>
> > - How to make the Inline API more formal.
> I don't understand this. could you please explain what you want to achieve.
Right now the Inline API is informal. It says: implement these 5 methods and
expect a hash object with certain values. I think I could formalize this into
a class called Inline::API. It's not a top priority.
> > - How to stay 90% backwards compatible.
> Warning, backward compatibility ahead!
>
> If a major refactoring is to break backward compatibility then let it
> break. This is IMHO the only way to have a sound design in the re-factored
> code. Now this might sound like users with legacy code are to pay for
> this, they do not. Legacy code owners still have the old libs those libs
> can still be made better (may be by using some part of the new design).
> The important point is to have the ability to run both parallely. This is
> what COM, for example, does, a facility can offer multiple interface
> versions co-existing in the same objects
I'm not against breaking a few eggs. But I don't think i need to do anything
radically different. I like the way Inline works. I just want to drop support
for some of the more esoteric TMTOWTDI features that I threw in. If those
things break, and people scream, I put them back in. No big deal.
Cheers, Brian
