Andrei Thorp <gar...@gmail.com> writes: > Proposed solution: Make a database of signals. Perhaps someone has a > better idea than this, but here's mine. We create a set of nested > tables in awful. This is pretty much just a large collection of > globals. They would be named like: awful.signal.client.prop.border. > Each of these variables would have a string associated that is the > property string currently used. Ex. awful.signal.prop.border = > "property::border". Then: > - When code wants to emit or catch a signal inside awful or the C > side, it can access these variables. (C side can read awful lib > variables, right?) > - We document the variables using the standard luadoc stuff and get > rid of the wiki Signals page. > - We reduce the chance of typos. > - We increase consistency of the variable names because they're all > defined in one place. > > Thoughts? Improvements? People willing to implement this?
That's a good way to go IMHO. Ideally, signals should be objects and not strings, and probably accessed via signal.* namespace or client.signal.* or something like that. Even more ideally, emit() should be implemented to not a emit a "signal" object or string, but ANY object. Then you may be able to create some sort of Signal class if you want to emit them, but you're also free to not. (Rah. Actually, that's a shame I already did that in Bazinga. :) -- Julien Danjou // ᐰ <jul...@danjou.info> http://julien.danjou.info
pgpTM8oJliidx.pgp
Description: PGP signature
