On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote: > Hi, > > On Tue, 10 Apr 2012, Xinliang David Li wrote: > > > >> > exp->as_component_ref().get_field() .. > > > > Actually it's not questionable. The above stuff is _horrible_. > > > > Specifics please. It is _horrible_ because you are more used to the > > existing way and the new style does not match your taste or they are > > very hard to understand and use? > > Your style (I wouldn't call it The New Style) is visually distracting, and > therefore harder to understand and use, longer to write and full of > syntactic noise without any whitespace. Quite frankly, how anyone could > ever say that > > exp->as_component_ref().get_field() > > is easier to read/write/use than > > GET_FIELD_DECL (exp) > > (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without > all-caps, is completely beyond me. I pretty much hope that we never see > the ugliness of the first way in GCCs code base. Even in C++ it's > possible to write non-spaghetti code.
I don't see how this is spaghetti code. It it slightly longer, but that's just the case in this specific example. Think about programmers new to GCC for a second, and about code completion tools. It seems to me that with such a tool it's much easier to navigate from exp to the field, than having to scan through a much larger number of accessor functions / macros (GET_*). The former example starts at the source (exp) and yields/"builds" the result; the latter names some function and then says applies it to the source. Why is the former so much worse? To me, the former's structure is easier to see, and if I would have to put the spaghetti tag on something, then the latter. Also, how do you envision code completion to work with the latter? Type exp first, and then have it show which functions take arguments compatible with exp, and then replace it? If a programmer doesn't remember all of the GCC APIs, code completion tools are very convenient. Torvald
