On 10 September 2012 16:54, Gabriel Dos Reis <g...@integrable-solutions.net> wrote: > On Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray <aaronngray.li...@gmail.com> > wrote: > >> What I am looking to obtain is isolating the C++ parser with no real >> semantic changes, just isolating the interfaces in order that the >> parser be reusable as a library component and allow migration to other >> solutions. > > Yes, for that, you need reduce the scope of your patch. > > Use Occam's razor. Do not move a declaration out of cp/parser.c unless > you have a compelling reason for it.
Okay. > "Classization" is not sufficient argument. Its an incremental step forward. > A good interface is likely to be reduced to the essential. > > I would suggest that you do not create any file out of cp/parser.c for the > moment. Just focus on identifying the interface of the parser within > cp/parser.c. It is actually two "generic" cross frontend functions that are linked to and not actually declared in parser.h - 'c_parse_file()', via cp/cp-lang.c and 'pragma_lex()', used by cp/lex.c. But yes I agree. This comes down to 'cp_parser::translation_unit()', afaics this is the only method that needs exposing in cp_parser. > Do no move data types out of cp/parser.c unless there is a good reason for it. Okay agreed. > If an existing function does not "poke" into what should morally be > (private) data members of the cp_parser struct, don't make it a > member function yet. I made most statics. And also the next stage of making it a class and member functions private would mean you would have to declare these function friend functions ? > If a function does, then look at whether it can > be expressed in terms of more reduced set of observer/mutator functions; > if that is the case, then do that. Adding the observer/mutator function does > not change semantics. Isolating the interface means isolating the > computational > basis. I think this is another stage of abstraction all together. Aaron
