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

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

Grzegorz Jakacki wrote:

 >>So reverse-engineering is what takes 90% of my time. Once I understand a
 >>given design it's quite easy to see whether it can be enhanced.
 >
 >
 >My take is that 100% understanding in these circumstances is not
 >precondition to introducing changes. But this is MHO.

I fully agree, and I have never said anything else. It's an iterative
process...


 >>As we now agree to redesign the parser such that it does the declarator
 >>recording (Environment...) itself instead of letting it done by a Walker, it
 >>could mean that the Walker could be part of the high level.
 >>Right now it can't because parsing isn't complete (i.e. self-contained)
 >>without ClassWalker.
 >
 >
 >Wait a moment. I don't think it is *that* easy with C++. As I already
 >mentioned here several weeks ago, I don't see a way to perform type
 >elaboration in one pass. This is because
 >
 >    The potential scope of a name declared in a class consists not only of
 >    the declarative region following the name s declarator, but also of all
 >    function bodies, default arguments, and constructor ctor-initializers
 >    in that class. [3.6.6p1]

yes, yes, I acknowledge. My wording was poor. I understand that parsing
can't be a linear sequential process. The design I have a problem with is
the fact that in the Walker framework multiple things seem to be lumped
together: on the one hand it appears to operate on the meta object level
(user keywords), and on the other it seems to participate in the parsing
(the 'second stage'). Is that not so ?

The construction of scopes (i.e. symbol lookup tables) can be done during
the parsing, right ? There is just no reason to do this stuff in the same
object that looks for user keywords !

Walkers *should* only care about the mop stuff, and thus all the lower level
classes (ptree, parser, encoding, etc.) should be free of any reference
to Walkers.


 >Here we just cannot rely just on one pass. It seems to me that a reasonable
 >solution is that parser stores the function bodies, default arguments and
 >ctor-initializers and parses them after the class is parsed. At that
 >time the symbol table can meaningfully answer if a given name represents
 >a template.

yes, sounds good. What I'm not clear about is whether this would involve
high level types such as 'Class'. Put differently: should 'Class' be part
of this parse process ? Where do you draw the line between 'core' and 'high
level' ?

 >>It records declarations to the Environments, and these are then necessary
 >>to complete the parsing, no ?
 >
 >
 >I don't think OpenC++ does it now in such manner. AFAIK parser does not use
 >type information to resolve any syntax ambiguities (ie. at template
 >instantiations).

that may answer my question why I don't see any ptree changes between
before and after the translation. If I understand you right, the translation
only changes the ptree if there are user keywords ('metaclass' and co.) in
the
input, which may be expanded. Can you confirm this ?

 >>'Encoding' is a 'passive' data holder (similar to std::string). In this
 >>role I placed it into PTree nodes, to make them more type safe.
 >
 >
 >Personally I don't like it, because it forces clients data structure on
 >parser library.

not in my case, where 'Encoding' has become part of the 'parser library'.

 >Putting functions from EncodingUtil into Environment makes sense only if
 >they need private access to Environment. They don't.

hmm, from my point of view a function belongs to a class if it is
conceptually
related, not if it needs access to the class' private members. Things like
'GetBaseName' operate on both, Encodings as well as Environments. You could
argue for both, associating them with Encodings as well as Environments.
But as since without it Encoding wouldn't depend on Environment, I think it
is more natural to put it into the Environment...

 >If you feel that 4 functions in EncodingUtil namespace does not warrant its
 >existence, then I would suggest putting them in Environment.h (but not as
 >member functions), according to Sutter's "interface principle".

yeah, they may be static.
[while I think 'principles' reflect 'common sense' and generally accepted
'good practice',
  I wouldn't want to be dogmatic enforcing them. They are just principles
after all...]


 >I think that your contributions to original OpenC++ that currently
 >constitute C++ submodule of Synopsis are very valuable and I would be glad
 >to leverage them in OpenC++ Core. As I understand the only changes that
 >were made under LGPL to OpenC++ 2.5.12 under Synopsis are yours, right?

No, they are mine as well as from Stephen Davies (whom I'v lost track of,
unfortunately).

 >If so,
 >would you consider donating them to OpenC++ under OpenC++ license?

what is the 'OpenC++ license' ? How is it different from LPGL ?
What makes you not want to use LGPL ?
And, without wanting to get into a flame war, a question to all developers
on this list:
Does anybody *not* want the code to be distributed under LGPL ? If so, why ?

Regards,
		Stefan