RE: [XaraXtreme-dev] Tools folder - what is it good for?

["Charles Moir" <CharlesM@xxxxxxxx>]

I'm fine with this then (changing the cdirectory structure), as long as we keep these modular things in mind.

Charles

> -----Original Message-----
> From: Phil Martin 
> Sent: 24 March 2006 21:55
> To: Ben Summers
> Cc: Alex Bligh; Charles Moir; dev@xxxxxxxxxxxxxx
> 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  
> minimal.
> 
> 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- 
> compatibility.
> 
> Phil
> 
> 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  
> >>> little  more
> >>> 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)  
> >> specify
> >> which bits of API would need such auto-generation. Tools (quite  
> >> correctly)
> >> 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.
> >
> > Ben
> >
> >
> >
> >
> 
>