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

[Grzegorz J. <ja...@ac...>]

Hi!

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

Yes I have. I have not got down to visitors, so this is one difference. 
I got rid of metaclass- and translation-related stuff, as I think this 
is the domain of a client (Greater OpenC++) not the OpenC++ Core. I have 
also seen that you have done some renaming in Ptree hierarchy; I kept it 
as it was, so this is yet another difference. That's it for the quick 
glimpse.

In fact I contemplated starting from your files, however it would force 
LGPL on OpenC++ and I am not sure if this is the right thing to do.

> 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.

I think it is suboptimal in this case for two reasons. First, there is 
very little documentation of existing system, so almost all 
documentation would need to be reverse engineered (I already did some of 
it, as you may remember). Second, we cannot provide accurate unit tests 
post factum, because we are not sure what the code should really do.

I think that the way to go is to read and clean the code step by step, 
adding unit tests as the knowledge about the code grows.

> Some months ago I proposed a rigorous separation between 'parser' 
> (including
> ptree API) and higher level classes (Environment, TypeInfo, Class, etc.).

In fact parser separation started several months before you joined in 
April. (http://sourceforge.net/mailarchive/message.php?msg_id=6971830)

> Now that my understanding of occ internals is a little better, I would
> revise my suggestions I then made. 

Go ahead.

> Still, I believe that I'm not the only
> one whose understanding is limitted, 

You are not the only one. Count myself.

> 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 ? 

More detailed question solicited.

> What is the Walker's role ?

I believe that:

Walker -- does preety nothing, just traverses the subtrees. It is a 
"skeletal implementation".

ClassWalker --- traverses the AST and creates metaobjects (objects 
representing semantic entities of C++, e.g. objects of classes Class, 
Member etc.)

ClassBodyWalekr --- traverses the AST of classes and also creates 
metaobjects (perhaps difference between ClassWalker and ClassBodyWalker 
stems from the fact that in C++ binding in class scopes works 
differently than in other scopes).

> How are Encoding and TypeInfo related ?

It seems to me that Encoding is always an "expanded" type, while 
TypeInfo is "lazy" type, e.g. it can buffer referencing/dereferencing
and also it can keep typedefs unexpanded (that's why it needs to have a 
link to Environment).

There also another point to it: if I am not mistaken Encoding can encode 
not only type, but also scoped identifier.

> Without better understanding these and other questions I'm unable to 
> suggest where to draw the line between low level and high level.

I am afraid there is no single person who understand (or remembers :-) 
this all clearly today.

> 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.

How does it relate to OpenC++? What would you suggest for OpenC++?

BR
Grzegorz