Re: [orbitcpp-list] announcing o2cpp

[Phil d. <ph...@us...>]

Andreas Kloeckner wrote:
> 
> Hi,
> 
> I'd like to announce to you the initial release of "o2cpp", version
> 0.10. o2cpp is (to become) a c++ mapping for orbit. Accidentally, you're
> trying to achieve the very same thing. Some of you may remember me
> asking last summer whether you'd need people to do a c++ port, well, the
> answer was "no,thanks", so i started over from scratch, which taught me
> a lot about corba, took about two weeks to write 99% of the code, then
> uni started again, i got busy with other things, and so it took another
> six months to let things culminate in this release.
> 

Cool - was I really that rude?

> "Now why does this guy redo all the stuff we did?"
> --------------------------------------------------
> 
> * Choice of language
> 
> I believe Python is not quite the optimal choice of a language for a c++
> mapping, yet, one can debate that. my implementation is 100% pure c++.
> 

Fair enough (BTW, it's only the compiler that's written in python - all
of the runtime is and will be in C++). What didn't you like about
python?

> * IDL compiler design
> 
> At that time, you were using the visitor pattern as the main build
> scheme for your compiler. I don't know whether this is still true, but
> when I looked at it from a distance, it did not please me much out of
> one reason: Its use of inheritance and polymorphism in this setting is
> restricted. Thus, along with a new language, I am proposing to you a new
> compiler design: With my implementation, I have a class for every kind
> of IDL element, which in turn knows how to spit out its code if
> appropriate (e.g., cIDLType has a pure virtual method
> "writeCPPStubMarshalCode", which does so for any type given) Thus, any
> given type can be handled by the same code, and (e.g.) typedefs are
> straightforward and easy. Uh, this description isn't too good, but I'm
> sure you'll instantaneously get the point when looking at the code.
> 

I like the idea of having a single class for each IDL type - this may
well be a better design than my idl compiler. (Adding a new type still
requires changes to a number of files in my compiler)


> * Implementation integrity and robustness
> 
> Six months ago, some parts of the code seemed just not the way I'd liked
> them to be, mainly the "runtime" parts, i.e. ORB and POA stuff, as well
> as much of the generated code in the skeletons. Obviously, you will have
> made a bit of progress, so this may not be a point any more.
> 

To be honest, the runtime orb code is a bit 'fit-for-purpose'. When we
(Ronald and I) wrote it we were really looking to get something working
rather than making it a beautiful as possible, so a re-write is
definitely in order.

> "Why should the ORBit-C++ project care?"
> ----------------------------------------
> 
> Counting that two teams trying to do the same thing in basically the
> same manner do not cooperate makes both teams achieve less than they
> could.

Agreed.

> I have taken things so far as to not just be standing there, saying:
> "But wait, I want all this in C++!". I thought my request would be a bit
> more convincing if there was a base to start porting upon, so I decided
> to lay that base, and here it is.
> 
> After all, this project was always intended to augment, not to void your
> efforts.
> 

Cool! I have no qualms about an idl compiler rewrite in C++, and it's
certainly true that the runtime code *needs* rewriting.

What's your plan? Do you want to join forces / merge code? 

Cheers,

Phil.

(BTW, I've put my thoughts and comments about the o2cpp implementation
in another mail)