[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Tools folder - what is it good for?
- From: Phil Martin <Phil@xxxxxxxx>
- Date: Fri, 24 Mar 2006 21:54:57 +0000
- Subject: Re: [XaraXtreme-dev] Tools folder - what is it good for?
I think the original plan for modularising bits of Camelot was
similar to this "shimming" of which you speak.
We were going to create wrappers that presented well-defined, fixed
interfaces to the outside world and which internally called down to
the C++ objects. But we probably would have created (or tried to
create) the wrappers manually rather than auto-generating them. This
would have been tedious but might have helped to keep the interfaces
Since then we have also had the examples of XML and HTML DOM's to
study. They present an object-oriented interface to the world but are
very careful to tie down their interface definitions once they have
been published and only add new functionality by adding entirely new
interfaces, leaving the old interfaces still working for back-
On 24 Mar 2006, at 18:59, Ben Summers wrote:
On 24 Mar 2006, at 18:46, Alex Bligh wrote:
--On 24 March 2006 18:35 +0000 Ben Summers <ben@xxxxxxxxxxxx> wrote:
So, would it be possible to auto-generate a C binary interface which
doesn't change when you change the C++ object? Could it be
than a shim layer? And I'm sure it could be source code
compatible, so a
plugin could be compiled in without the shim layer.
I am not sure how "auto-", but yes perhaps.
If you select the classes of interest, then use the output of nm to
find all the relevant functions in that class, you should be able
to do something simple but effective which will insulate from
binary changes as the classes evolve.
But I still think the current
directory distinction is not helpful. It doesn't (for instance)
which bits of API would need such auto-generation. Tools (quite
call into the Oil layer, for instance to get resources. Part of the
issue here would be designating which bits of API are meant to remain
stable, so they could be "en-shimmed".
I didn't mean to suggest that the whole task would be easy, just
that the use of C++ itself should not be a barrier.