Re: [Opencxx-users] OpenC++ Core Lib -- prototype

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:
> Hi,
> 
> The new module in CVS called 'occ-core' contains my first attempt at
> launching the "OpenC++ Core" initiative. Throughout the last week
> Stefan Seefeld and myself were discussing the possibilities of having
> a common repo for the core part of OpenC++ reused by Synopsis, but some
> unsolved issues still remain, thus I decided to demo my idea in an actual
> code.
> 
> As outlined in "OpenC++ Core Lib MANIFESTO", OpenC++ has problems with
> advancing the quality of code analysis (templates and overloading),
> because along with advancement in this areas, other parts of the system 
> need to be accordingly maintained, which distracts the resources. Thus 
> the idea to take out the core functionality pertaining to code analysis
> and make it into compact, self-contained and self-testable library.
> The division would separated code into "OpenC++ Core" (lexer, parser,
> code object model ("Class", "Member"), type elaboration) and
> "Greater OpenC++" (translation, metaclasses).
> 
> 'occ-core' is a first attempt to group the "OpenC++ Core" and make it
> self-contained. To checkout (non-developers):
> 
>   export CVSROOT=:pserver:ano...@cv...:/cvsroot/opencxx
>   cvs login
>   cvs -z3 co occ-core

'no such module' is all I get. That's probably because the anonymous
access is seeing changes with some hours of delay. Using my developer
login works.

Did you have a look at the redesign I did inside Synopsis ? How does
your occ-core compare to that ?

I'd generally much prefer to start with an assessment (i.e. documentation
in terms of actual text, unit tests, and examples) of the existing design.
Some months ago I proposed a rigorous separation between 'parser' (including
ptree API) and higher level classes (Environment, TypeInfo, Class, etc.).

Now that my understanding of occ internals is a little better, I would
revise my suggestions I then made. Still, I believe that I'm not the only
one whose understanding is limitted, and so I believe in order to be able
to make 'educated suggestions' we should start by discussing the existing
design.
In particular, how does parsing work in detail ? What is the Walker's role ?
How are Encoding and TypeInfo related ?
Without better understanding these and other questions I'm unable to suggest
where to draw the line between low level and high level.

Regards,
		Stefan

PS: I consider the redesign I'm doing in Synopsis as an iterative process.
     I work my way up starting from the lowest layers, and while I get a better
     understanding on the individual classes I'm able to improve their design.