droundy:
On Fri, May 04, 2007 at 06:07:52PM +1000, Donald Bruce Stewart wrote:
dons:
David, Spencer et al, are there any problems with restricting layoutMsg arguments to being members of the (open) Message class? I'd (strongly) prefer this over just Dynamic, since it restores most of the static checking we'd need.
Oh, I forgot an example. This is why Dynamic-only is scary:
, ((modMask, xK_h ), layoutMsg "hey Joe!") , ((modMask, xK_l ), layoutMsg Expand)
is well typed. Under the new system, it becomes a static error:
Config.hs:157:43: No instance for (Message [Char]) arising from use of `sendMessage' at Config.hs:157:43-65
I personally like the ability to send unaccepted messages. It can't pose a
You can still send unaccepted messages, but you can't accidentally send a non-message type anymore.
problem on the receiving end, since every layout has to be able to handle messages it knows nothing about. So the only danger is foolish users who
Right.
send messages that have no effect, but that really seems harmless to me. I guess getting better error checking is nice, but it seems like you're talking about error checking for something that really isn't likely to be a problem.
Well, its pretty light, and more static checking is always good, in my view. This guides the user a bit more towards valid code. Is there any downside?
This is different from the NonEmpty list issue, which still is working on avoiding the dangers of foolish users--who define an empty layout list--but in that case those foolish users could actually crash xmonad, rather than simply defining a key binding that has no effect.
And that issue is fixed today, too, safeLayouts = case defaultLayouts of [] -> (full, []); (x:xs) -> (x, xs) I think the combination of a Message class, and the non-empty layout handled via another mechanism, covers the holes we opened up. -- Don