Re: [Opencxx-users] future directions

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

Hi Stefan,

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>>> And I don't see a problem having two separate constructors, one 
>>> operating
>>> on Ptree pointers, the other on the typed counterpart.
>>
>>
>>
>> I am not sure if you get the exact picture. The "untyped" constructor 
>> does not construct the NonLeaf auxiliary nodes. It is just:
>>
>>
>>     PtreeIfStatement(Ptree* p, Ptree* q) : NonLeaf(p, q) {}
>>
>> If we have another, "typed" constructor like this one:
>>
>>     PtreeIfStatement(
>>         PtreeExprStatement* cond
>>       , PtreeExprStatement *th
>>       , PtreeExprStatement* el
>>     )
>>       : NonLeaf(cond, new NonLeaf(th, new NonLeaf(el, NULL)))
>>     {}
>>
>> Then, as you noticed, there is a question of who owns auxiliary
>> NonLeaf nodes (and, consequently, if ~PtreeIfStatement should delete 
>> them).
> 
> 
> right, but I didn't mean the 'typed constructor' to construct any nodes
> himself, but rather to take 'PtreeExprStatement' arguments instead of 
> 'Ptree'.
> The ownership semantics remains the same.

Stefan, look again at the picture: immediate "physical" children of 
PtreeIfStatement are not PtreeExprStatement nodes. They do not have any 
reasonable type in the sense of C++ grammar. They are only glue nodes.

Having said that, I don't understand how can PtreeIfStatement take 
PtreeExprStatement nodes and at the same time not construct any nodes 
itself.

> 
>>> That sounds indeed like a bad idea. Either Ptrees
>>> own their children, or they don't. 
>>
>>
>>
>> I agree. However I am not sure what you mean by "child". What is a 
>> "child" of PtreeIfStatement node? Do you consider "else-part" to be a 
>> "child" of PtreeIfStatement node?
> 
> 
> yes.
> 
>> It is also not clear to me if you would like to keep the existing 
>> representation of if-statement as three physical nodes or if you 
>> eventually would like to modify PtreeIfStatement so that it becomes
>>
>> struct PtreeIfStatement
>> {
>>     ...
>>     PtreeExprStatement *cond_, *then_, *else_;
>> };
> 
> 
> the latter.

Then, as I described in my last e-mail, there is huge amount of work 
involved in transforming all the legacy code that deals with "glue" 
nodes. Every single piece of code that accesses, say, "condition" of 
if-statement, will need to be changed from 'p->Cdr()->Car()' to
'p->GetCond()'.

Your solution is very clean, but it requires a huge investment. My 
suggestion is to leave the legacy code as it is and provide NodePtr<> 
atop of it. NodePtr<old_PtreeIfStatement> would very closely mimic 
behaviour of new_PtreeIfStatement*, so where is the gain?

Moreover, if you ever change parser or elaborator, you are free to mix 
the code that uses NodePtr<> with the legacy code. Even more --- if one 
day you discover, that you eradicated all occurences of PtreeXXX, Leaf 
and NonLeaf from parser, you can implement your clean classes a la the 
PtreeIfStatement above and just textually replace every NodePtr<Foo> 
with new_Foo* and you are done. My solution arrives exactly at the same 
point that you want to reach, but it seems to me that the landing is 
much softer.

Best regards
Grzegorz

--------------------------

WRAP-UP
=======

Instead of introducing

   class new_PtreeIfStatement {
       ...
       PtreeExprStatement* GetCond() { return cond_; }
       ...
       PtreeExprStatement* cond_;
   };

and fixing all the places in code that will get broken by replacing 
PtreeIfStatement by new_PtreeIfStatement, let's introduce

   template <>
   class NodePtr<PtreeIfStatement> {
       ...
       NodePtr<PtreeExprStatement> GetCond() const {
           return NodePtr<PtreeExprStatement>(
               (PtreeExprStatement*)(p_->Cdr()->Car));
       }
       ...
   private:
       PtreeIfStatement* p_;
   };

and leave the legacy code as it is.

NodePtr<PtreeIfStatement> works essentially as new_PtreeIfStatement*,
it can be further enhanced to mimic newPtreeIfStatement* very closesly, 
including pointer syntax.

All uses of Ptree* derivatives can be gradually replaced with NodePtr<>. 
Once all of them are eradicated, every NodePtr<Foo> can be replaced with 
new_Foo* (and that will not require any further code tweaking), which 
effectively provides smooth, evolutionary way of arriving at the first 
solution.

----- END OF WRAP-UP -----


> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users