Re: [orbitcpp-list] idl compiler has arrived

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

Andreas Kloeckner wrote:
> 
> "Braden N. McDaniel" wrote:
> >
> > It seems to me that for a project like this it just makes a Whole Lot Of
> > Sense to use the same naming convention as the C++ binding to CORBA. I've
> > found that I can adjust to just about any naming convention after staring
> > at it long enough, but consistency is *important*.
> 
> yes it is, but one needn't interpret this so stiffly. With the CORBA
> spec naming convention on the one side and some other convention on our
> side (which would never be visible to an outside user of the package, of
> course) it would be extremely easy to determine from the code which is
> implementation detail and which is outside interface. Likewise, the
> compiler is almost completely disjoint from any corba spec namespace, so
> there's well some space to choose. phil?

2 forces affect the decision:

1) Consistency
2) Amount of work to change it

Re (1): I agree with Braden that (a) it is desirable for all the code to
be consistent, and (b) the coding standard should mirror the C++
language mapping standard since that's the thing we can't change. I
don't agree with the idea that we should encourage inconsistency due to
the split between proprietary code and spec compliant code, since we
implement spec methods using proprietary code and the whole thing could
get very confusing to a newcomer. 

Re (2): I don't want to spend time converting the compiler code to meet
the C++ language mapping coding style.

So I propose we attempt to do the following (in the short term at
least): 

1) We use the C++ language mapping style (underscores etc..) for the
runtime:
	- All the code in the orb directory
	- The generated stubs and skeletons

2) We use Andreas' coding style (but not indentation style ;-) for the
idl compiler since it appears to be fairly complete, and changing it
represents a fairly large and tedious task. 

I'd add that if somebody wants to change the idl-compiler style to match
the c++ language mapping later then I think that may be a good thing(tm)
from a maintenance point of view.

Does this sound like a good plan. (At least for the short term future?)

Cheers,

Phil.