Personally I like C APIs, they seem to be easier to maintain. I was once force to implement an API using pure virtuals and it was hell dealing with binary compatibility breaking all the time (well hell for the people using the API :)).
Yes, the internal objects can be whatever you want. That is the beauty of the pimpl. I don't know of any automated tools, but I don't think it would be hard to write one. Most of the time all you are doing is calling the same method call on a pointer to the real implementation. -Bryan On Nov 25, 2009, at 2:12 PM, John Plevyak wrote: > > Good point. So non-virtual functions which would imply wrapper objects > for internal objects with virtual functions. I wonder if there are any tools > to automate that. > Sigh. This is getting complicated. C++ is a pain. Makes me think the C API > isn't so bad. > > john > > Bryan Call wrote: >> Have pure virtuals ties us into not being able to expand the API for the >> class without breaking binary compatibility. I would rather see a private >> implementation design for the API instead. That way if we want to expand >> the API to add functionality it won't break binary compatibility. >> >> -Bryan >> >> On 11/25/2009 11:34 AM, John Plevyak wrote: >>> >>> Given that the existing C API is often a wrapper on an internal C++ API, >>> there is a natural >>> mapping of just using the existing internal C++ APIs as the InkAPI but just >>> convert them to be pure virtual. This would also encourage clean internal >>> APIs to make it easier to use for the InkAPI. I am not sure about the >>> whole setter/getter >>> vs exposing some stable data structures vs smarter higher level interfaces, >>> but perhaps >>> these are better considered on a case by case basis. >>> >>> Doing internal C++ to external C then wrapping the external C with external >>> C++ is going >>> to result in a lot of code to be maintained unless we can automate it in >>> some way. But >>> if it is automated then perhaps we can automate a native extern C++ >>> interface as well. >>> But if it is automated then why not just use SWIG to do the automation and >>> why not just >>> use SWIG to automate the external C from the C++ which we have an internal >>> version of already? >>> >>> Anyway that was the train of logic I went down.. of course it becomes more >>> tenuous the >>> farther you follow it, but it is still interesting to consider. >>> >>> john >>> >>> >>> Leif Hedstrom wrote: >>>> On 11/25/2009 11:43 AM, John Plevyak wrote: >>>>> >>>>> >>>>> << transfer from IRC>> >>>>> >>>>> Here is a proposal: >>>>> >>>>> 1. C++ APIs >>>>> 2. Clean SWIG for supporting other language >>>>> (in other words, the C++ APIs would have to work well with SWIG) >>>>> >>>>> Open question: do we expose some very stable data structures, e.g. >>>>> IOBuffer, VIO ? >>>> >>>> >>>> So, what exactly would change in the APIs? Are we going all out OO, and >>>> everything becomes class methods, getters/setters etc.? If we do this, we >>>> should do an equally drastic redesign of the Remap APIs (and no more >>>> struct passing etc.). >>>> >>>> As an alternative, how much worse would it be to have a low level C API >>>> (that we expose) like today, and then make a higher level object oriented >>>> API that wraps the C APIs? >>>> >>>> For sure, now is the time to do any major changes like this :). >>>> >>>> -- Leif >>> >> >
