On Mon, Jun 25, 2001 at 04:37:11PM +0200, Oren Ben-Kiki wrote:
| null: ~
Ok. Let's add a node type then.
| > Speaking of the API. I think that I'm going to
| > re-write it using a very weak subset of C++
| > rather than C.
| I don't think it is a good idea:
| - There's a benefit for using ANSI C, especially for the
| lower end (embedded systems etc.).
| - It seems trivial to convert a "weak C++" API to
| a proper C one: convert each class to a struct of
| function pointers and add a 'self' parameter to
| each method.
This is what I'm doing. However, to be compatible
with COM, I should re-write it so that each "object"
is a pointer to a pointer to the function table. And
then I should leave the first 3 function pointers
blank (these are needed for IUnknown).
I'd like the C implementation to be the standard COM
binding so that Visual Basic, and any other Windows
based object-oriented system can use YAML via COM.
| - Relying on things like istream/ostream in a C API
| is impossible anyway - it is one thing to assume
| the complier knows what an interface is, and a
| completely different thing to drag the C++ I/O
| library into a program!
| The current yaml.h file is probably the right approach for
| purely-streaming C-only API. You did an admirable job in
| unifying the push and pull APIs. I'm a bit more ambitious.
| I want the pull/push APIs to be *exactly* the
| iterator/visitor APIs to the random access data structures.
I'd like to hear your suggestions before I go off and
start "implementing" first thing next week. (I'm on
a tight deadline now... otherwise I'd be doing it this week).
| This is easy enough to do for Perl and Python (or even Java)
| which don't have a developed iterator concept (they have
| 'next' - fine, so do we, we can be compatible with the
| "standard" iteration idioms).
Right, and the Python binding (over the C interface)
will support python-style iterators.
| In C, "anything goes" - there are no standard iterator/visitor
| idioms. So yaml.h is probably the best approach you can take there.
| I'd still like to see it integrated with a random access structure,
| however! And I do have some technical nits to pick there - I
| need to go over it carefully first, though.
| In C++, however, my ambitious requirement above means being
| STL-friendly to some degree. You'd also want to use the
| standard string class - and ownership issues may be handled
| to some degree by auto_ptr - and so on. In short, I think
| it is going to be hard to keep the C and C++ APIs compatible.
Right, which is why I was thinking more the COM route.
| It is probably not going to be practical to even layer the C++
| implementation on top of the C one.
Well, we could have a thin wrapper... but then this
wrapper might not be STL compatible. However, if
we can make the C interface like STL, this would
at least reduce the impediance mis-match.