[ I am adding back GCC mailing list in the CC: as this would be useful for other contributors. ]
On Mon, Sep 10, 2012 at 9:42 AM, Aaron Gray <aaronngray.li...@gmail.com> wrote: > On 10 September 2012 15:25, Gabriel Dos Reis <g...@integrable-solutions.net> > wrote: >> >> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray <aaronngray.li...@gmail.com> >> wrote: >> > On 10 September 2012 14:35, Gabriel Dos Reis >> > <g...@integrable-solutions.net> >> > wrote: >> >> >> >> On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray >> >> <aaronngray.li...@gmail.com> >> >> wrote: >> >> > Hi, >> >> > >> >> > I have put in three patches on the 29th of August, but have not heard >> >> > any real feedback on them :- >> >> [...] >> >> > [PATCH] C++'ization of cp/parser.c/h >> >> > >> >> > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html >> >> > >> >> > >> >> > This last patch possibly needs freshening, but all were tested and >> >> > tested with the GCC testsuite. >> >> >> >> You did receive a real feedback on the last patch. >> > >> > >> > Gaby, >> > >> > In reply, I was trying to do the first phase of a set of incremental >> > changes >> > towards normalizing the C++ frontend. >> > >> > Having looked at the complexity of parsing C++ and the complexity and >> > pragmatics of the semantics and the complexity of the GCC C++ >> > "middleend" >> > code and know it to a degree then to have something working keep it >> > working >> > seems the best bet to me. >> > >> > So the interfaces can be made distinct and normalized while keeping the >> > code >> > running and passing the testsuite. Once the interfaces are distinct more >> > radical changes can be made. >> > >> > Just my 2cents, >> > >> > Aaron >> > >> >> Aaron, >> >> I am not sure I understand what you are saying. >> The patch I commented on was *radical* change from the current state, and >> there >> is no answer to why you needed to make such a radical change, > > > As I understand things we are C++'izing the GCC C++ frontend ? > > And encapsulation and class'ization seems to be the first step in doing that > I would have thought ? It is not clear what the benefit is to move existing perfectly working internal non-member functions to being member functions a huge struct. Encapsulation does not necessarily mean that all functions have to be member functions or that all data type definitions have to reside in a .h file. In fact, I would argue that the patch you posted reduced encapsulation and abstraction, as opposed to increasing it. Datatypes and member functions that have no business of being exposed to the entire world are now made public. > My changes are orthogonal to the original code. No, they are not -- hence the comments. > All I have done is create > classes out of the cp_lexer_* and cp_parser_* functions and moved a few > statics into the classes where it was logical and where there were no weird > dependencies stopping that being done. You did not provide a rationale of why it was logical to move those functions as you did. The comments I made looked at the heart of the changes you made. -- Gaby
