Hi, Am Mittwoch, den 10.10.2007, 14:04 -0400 schrieb David Roundy:
We still would need the record definition in the core, as that is where hooks are called and where new hooks are added. And I think requiring the user to write
No, the core would remain unchanged, since the core API is unchanged, and the record would be defined in Contrib. Why would you need to define a record for your hook type in the core?
Because that’s where hooks are defined, after all. If we’d leave this to the Config file writer, then he’d still have to adjust the configuration file for each new hook that the core defines, which is what I want to avoid.
import XMonadContrib.CombineHooks
xmonadHook = combineHooks [ .. ]
instead of just
xmonadHooks = [ .. ]
whenever they want to use more than one extension, just to safe half a line of code in all the places where hooks are called does not seem to be worth it.
I'm not convinced that there will be such a proliferation of hooks that many users will ever do this. I suppose that's largely because I don't yet use any myself, and haven't seen any reason to define any.
I'd rather see the core API only complicated when there's a feature that can't be added without the complication (as happened with layouts) or when it makes things much simpler (or is needed for a reasonable core functionality, as with LayoutSelection).
I'd say that one line and a dozen characters added to the Config file is well worth the ability to experiment freely, and allowing us to see and try out code.
I think introducing a clean, simple interface for hooks for the user, and hiding the details in the type system means that just that: you can freely experiment (adding new hooks, changing the way hooks are implemented) without having the user adjust his configuration file. I don’t see how that complicates the core. Also note that there is a proliferation of hooks. At first, it was only the definition of key commands. Then came manageHooks. Later logHooks appeared. I’d almost bet that someone will want a initHook that runs once at start up. For propoer gap-STRUT-handling, an unmanageHook would be needed as well. I’d like to be able to add these hooks without breaking existing hooks and extensions, but also without having the user to figure out manually what extensions expose functions for what hooks and how to combine hooks from different extensions. I’d also like to stress that I’m proposing an interface for the Configuration and a possible implementation − if someone comes up with a more suitable implementation, even better! Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org