Re: C vs. C++: Deeper thoughts (Was: UrShape XML parser)

[Lennon Day-Reynolds <lennon kestrel edu>]

Okay, this seems to have gotten kind of disjointed; let me try to 
reiterate why I was pushing for the particular features and 
implementation I described earlier, and respond to some of the posts 
made over the weekend.

1. I have to agree with the crowd that is resisting the use of C++. I'm 
an OO guy all the way when it's feasible, but it's just not a good fit 
here. Why? Because in order for us to include even a single module 
written in C++ in Dia, we have to maintain *two* seperate bodies of 
code: the C++ 'UrShape' implementation, and it's 'glue code' to link it 
to the Dia core. Every improvement made to either our stuff or the core 
will have to be supported in multiple places, rather than simply 
updating a few lines of C, and we lose the portability and compatibility 
that C gives us. (Truth be told, I'd rather have a core in C, with code 
in Python handling most of the high-level functionality, but that's 
another project.)

2. The issue that I haven't seen anyone here bring up about XML Schemas, 
which is why I recommended using a small portion of them in the first 
place, is the support for primitive datatypes such as integers and 
floats (see http://www.w3.org/TR/xmlschema-2/, the 'datatypes' part of 
the spec). I wouldn't begin to suggest that we support the full breadth 
of the XML Schema spec for actual structure definition -- it's too big, 
and much more like UML-in-XML than a simple document validation tool. 
Our shapes will be simple, weakly-hierarchical objects with very little 
need for a powerful datatype definition syntax, or most of the other 
cruft that comes along with schemas.

3. Here's what I want to 'borrow' from the DOM:
	a. Simple, event/listener-based runtime binding of shapes on the canvas 
to C or Python code that gives them more complex behavior
	b. A consistent API for manipulation and acquisition of shapes, to allow 
generic handlers to determine their properties
	c. Support for arbitrary simple properties that are *not* part of the 
SVG/visual attributes, and may or may not be displayed in the property 
editor
	d. A simple interface to this internal 'mini-DOM' that can be used to 
create intuitive, flexible scripting language bindings

What I *don't* want from the DOM is the full, unweildly set of IDL-based 
interfaces, or the strings-and-nodes-only datatyping conventions of the 
core. Unfortunately, the existing libxml-based DOM implementation is 
mostly that, so we may be stuck 'rolling our own'.

4. As to using DOM or SAX to parse the XML, I really don't care; I 
usually use the DOM, but I'm usually coding in Java or Python, where 
it's a much better fit with the language. In C, using the libxml SAX 
interface (or even Expat, for that matter) seems to work just as well. 
I'm not worried about performance on this since you only load or save 
the file once in a blue moon compared to, say, moving an object on the 
canvas.

Sorry to keep posting these manifestos; after this, aside from answering 
direct questions, I'm going to try to avoid cluttering the list until I 
have some code to show for all my big talk. (And of course, if that 
never happens, then obviously you should have been ignoring me anyway ;)


Lennon Day-Reynolds
Software Engineer
Kestrel Institute