Dekel Tsur <[EMAIL PROTECTED]> writes:
| > | PS: The code in layout.C is horrible (all those cases).
| >
| > _why_ is it horrible. It used to be more horrible just a _huge_
| > switch. After the change the different layout contructs get parsed
| > separately and we get and warning/error reported if you have used the
| > layout format wrong. (it is not parsed as a flat format anymore)
| >
| > Lgb
|
| Consider the code of LyXLayout::readLabelType.
| It uses a LyXLex::lex() for converting the current token (defining the label
| type) to a number (of type LabelTypeTags), and then it does a big switch
| for converting the number to a different number (of type LYX_LABEL_TYPES).
| So why not make the call to LyXLex::lex() return the desired number?
| Namely,
|
| static keyword_item labelTypeTags[] = {
| { "bibliography", LABEL_BIBLIO },
| { "centered_top_environment", LABEL_CENTERED_TOP_ENVIRONMENT },
| ...
| };
|
| void LyXLayout::readLabelType(LyXLex & lexrc)
| {
| pushpophelper pph(lexrc, labelTypeTags,
| sizeof(labelTypeTags)/sizeof(keyword_item));
| int le = lexrc.lex();
| if (le == LyXLex::LEX_UNDEF)
| lexrc.printError("Unknown labeltype tag $$Token'");
| else
| labeltype = le;
| }
|
| Now, compare with current code of readLabelType ...
And how does the compiler tell you that you now miss some of the enums
that should/must be handled in the switch/if chain? Because that is
much of the point of the current code.
Lgb
