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

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

Grzegorz Jakacki wrote:

>>Your AbstractWalker's 'Translate' methods are not nearly as neutral and generic
>>as my Visitor's 'visit' methods. Just imagine you wanted to implement a ptree
>>serializer with it...
> 
> 
> I don't get your point. AbstractWalker is deprived of any implementaion.
> Are you refering to the fact that its method are called "Translate..." not
> "Visit..." ?

not really. More about the signature. The methods take a ptree and return
one. Why should a generic visitor return something ? As I said, just imagine
you'd implement a Visitor (Walker) that traverses the ptree to print it.
Or one that you use to find the type of a given ptree...
The 'Translate' method is just not sufficiently generic.

>>>* putting encoding in ptree is in my view wrong, because ptree should
>>>  not be concerned with how the higher levels represent types
>>
>>I don't quite understand what you have in mind. Do you suggest to remove
>>the PtreeDeclarator's 'name' and 'type' attributes ? I don't think that
>>would be a good idea, as the
>>parser is the best place to generate the encoding,
> 
> 
> Why?
> 
> Parsing is the best time to generate them. But parser is not the best
> place to generate them. Let the higher layer hook up to parser and
> generate whatever encodings it likes.

sounds very complex.

>>so if you don't store it inside the ptree you either have to
>>store it elsewhere
>>(but still build it from within the parser)
> 
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Why?

yeah, I get your point, but I don't agree about the usefulness of
a split there. I don't think parser is the right place to hook up
user code. As I said, Visitors to introspect the generated ptree
seems to me a much more elegant way.

>>, or you
>>have to regenerate it in a second pass (aren't we trying to get rid of
>>the second pass ?).
> 
> 
> It does not matter when they are generated. My point is that dependence of
> parser on one particular encoding used by one particular client is
> improper.

As I said, I don't see Encoding as 'one particular' representation. It's
OpenC++'s internal representation. clients can certainly hook up their
own with it.

>>hmm, the parser is a *very* rich class, so adding callbacks there appears
>>to me to be quite heavy.
> 
> 
> Look at this design:
> 
> 
>  +----------------+                                          |
>  | Parser         |                                          |
>  +----------------+       +------------------------------+   |
>  | ParseFoo...    |------>| AbstractParserClient         |   |
>  | ParseBar...    |       +------------------------------+   |
>  | RegisterClient |       | ParsedFunctionHeader(Ptree*) |   |
>  | ...            |       | ...                          |   ;
>  +----------------+       +------------------------------+  /
>                                          A                 /
>                                          |                /
>         LIBRARY    .-------------------------------------'
>         .---------'                      |
>  .-----'  CLIENT          +--------------------------------+
> /                         | ParsedFunctionHeader(Ptree* p) |
>                           |                  \             |
>                           +-------------------\------------+
>                                                \
>                                                 +---
>                                                 | annotates p node
>                                                 | with client-specific
>                                                 | encoding
> 
> How does it make Parser class "richer"?

well, you want to be able to hook up callbacks for individual ParseSomething methods,
i.e. you require the Parser to collaborate with AbstractParserClient so you can
implement it in the client.
I stand to what I said earlier: I believe you can get the same flexibility by running
a client visitor over the generated ptree and keep the parser as simple as it is now.

> Besides that, Parser is "rich" only because all parsing functions are there.
> It hardly provides any other functionality.

right, and that's quite enough.

> My personal view on implementing parsers is that it does not make sense to
> lump Parse... methods in one big class. Dependency hell, especially when
> parser state is private data and you need to add some helper functions in
> parser implementation. My opinion is that is is much better to define parser
> state as an object, and have Parse... functions enclosed in namespace. (But
> this is just a side-note, I don't think that this refactoring of parser
> would benefit the project at the current stage.)

agreed.

>>I believe this kind of flexibility is best provided by ptree visitors.
> 
> 
> I don't get you again. You said yourself that it is suboptimal to generate
> encodings by visitors.

right. I suggest to use the Visitor to glue client-side functionality to the
ptree. The Parser class should not be 'public' to clients. It should be
considered as a 'ptree factory' without much customizability. (client keywords
may be an exception, because there's no way around this.)

> As for those two top-level modules, I think that scripting implementation is
> the best. Why do you think C++ API is imporant (at this level)?

I don't think it's important, I just consider the possibility. If everybody
is happy with a python interface I'm quite happy.


>>I wouldn't call 'Encoding' a 'representation'. It's very minimal and
>>just enough to identify types and look them up. They can then be used as
>>keys into a user provided table to store 'client data', though.
> 
> 
> Is it specific to client or not?

The Encoding ? Definitely not. The client data you store in (client side) tables
for which encodings act as keys ? Definitely yes.

[...]

>>>>what is the 'OpenC++ license' ?
>>>
>>>
>>>See file COPYING.
>>
>>that file doesn't contain a license,
> 
> 
> Sorry, but this statement is clearly false. (Especially that in the next
> para you write, that it contains many licenses.) What do you mean?

sorry for the misunderstanding. I obviously didn't express myself clearly.
I didn't mean to hurt anybody's feelings with my description of the situation.
Sorry. Let me try to rephrase:

The COPYING file doesn't contain a single license (something I thought you
referred to as the 'OpenC++ license'). Instead, it contains five licenses
(sections starting with 'Permission to use, copy, ...'). Now please try to
view this from a lawyer's perspective who needs to assess the risks associated
with the use and distribution of this package. (Yes, I'v had to deal with
IP lawyers in various occasions, and I found it to be easiest when I could
*name* the license and show how it was already used elsewhere.)

In this sense I do believe the current situation is a mess. License proliferation
is a Bad Thing !

Anyways, I really want to avoid this to become a long thread, these topics
are being discussed elsewhere to death. Suffice it to say that I did choose
the LGPL for the reasons I outlined, notably what I consider to be developer
and end-user freedom. I'm not forcing this on anybody, but whoever wants to
use my code obviously has to comply with it (or else the license would be
meaningless).

Kind regards,
		Stefan