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
