This project has moved and is read-only. For the latest updates, please go here.

Grammar's instance methods/fields

Jun 27, 2013 at 6:30 PM
Is there a reason why the likes of Grammar.Empty and other such generic terminals are instance fields, and not static (ie, class) fields? I can't think of an immediate reason why a grammar would need to personalize Empty, SyntaxError, etc.

Also, the Hint utilities (and consequently Make* methods) and some Make* methods are all protected, non-virtual, but don't use any Grammar instance fields. Is there any particular reason why these aren't static as well?

Besides the unused 'this' parameter (which I realize is counting pennies, bare with me), this setup makes it impossible to formulate boilerplate code/extensions without having to define a 'common' base Grammar class (on top of Irony's Grammar), and it also means that CurrentGrammar has to be accessed (which is per-thread based, which is a potentially unneeded TLS lookup under the hood)

On a somewhat related note (okay, not really), is there a reason why you don't use XMLdoc for the documentation which does exist? Eg, one has to goto-definition for Grammar.LineStartTerminal to read the actual documentation. Probably a weak example, but as a 3rd party library it's typically helpful if end-coders don't have to leave their 'line-of-code-sight' in order to refer to a member's description
Jun 28, 2013 at 6:06 PM
The reason for predefined terminals being instance-bound, not static, is because the terminal is instance-bound itself (it has a reference to Grammar/parser data), so even if those terminals do not use it directly, it might be inconsistent. I thought about this, certainly making them static would make sense, but decided not to do the switch to statics
Hint utilities, and Make methods- same logic, some of them use Empty terminal which is instance-bound. I know, some arrangements might look strange today, but they are there mostly for 'historical' reasons - it just happened.
Xml comments - I know, I need to do better on these. My approach is usually is: write non-xml comments to explain tech details which do not need to show up in hint when the function is clear from the name of the element itself.
I know, lot of things to be improved, but just busy-busy-busy with many other things, and there's a list of priorities, and these are not on the top - we can live with that for now, right?
thanks for the suggestions, will try to improve what I can