Re: GCC contribution

[Katsunori Kumatani <katsunori dot kumatani at gmail dot com>]

Please don't change the lang_hooks into virtual methods. Speaking from a 
plugin development viewpoint, C hooks are very easy to override 
individually, without having to change the entire object or create a new 
one.

I realize that it's not the intended use for the hooks, and not why they 
were created. But they enable plugins to do a whole lot more, despite 
the limited plugin event callbacks already present (*especially* the 
targetm hooks!).

For example, I wanted to add some plugin processing (actually a 
top-level asm statement) at the end of a translation unit (with gathered 
data) to add some special symbols / GAS directives (not instructions). 
But there's no "normal" plugin event for this.

So instead I simply saved the original lang_hooks.parse_file hook 
(pointer), overrode the hook with the plugin's, which calls the original 
first and then does whatever plugin does. And it works fine. This kind 
of thing wouldn't be easily changed with virtual methods I believe.

Once again, I realize that was not the intended use for hooks, but it's 
a nice side effect and IMO should be kept.

Plugins suffer a lot from the "chicken and egg" problem (nobody wants to 
add events that would not be needed, but nobody codes plugins without 
enough events) and hooks kind of solve a lot of it, so that's a good 
thing (especially targetm, more so than lang_hooks).

I mean, if you had to first suggest an event and *hope* it gets added 
before even starting your plugin (otherwise it would be a waste of 
time), you'd just give up. Or at least, the majority would. At least 
with hooks, nobody needs to add anything for plugins, since you can 
override the C hooks directly from the plugin (while maintaining a chain 
for the old one).