|
From: lawrence m. <we...@gm...> - 2003-12-24 16:54:51
|
Jeremy Maitin-Shepard wrote: [...] > Refer to the code in the attached file. Note that I changed the format > of `erc-settings' to something that is both easier for the accessor > functions to deal with and also should be easier for users to deal > with. Specifically, the old format was: > (VAR nil VALUE) ; applies to all networks > (VAR NETWORK VALUE) ; applies only to NETWORK > (VAR (NETWORK CHANNEL) VALUE) ; applies only to CHANNEL on NETWORK > The new accessor functions use this format: > (VAR VALUE) ; applies to all networks > (VAR VALUE NETWORK) ; applies only to NETWORK > (VAR VALUE NETWORK CHANNEL) ; applies only to CHANNEL on NETWORK This makes more sense, I suppose, though, I like the original version in a way, since CHANNEL is explicitly tied to NETWORK, whereas with your format it isn't. How about (VAR VALUE (NETWORK CHANNEL)) ? > You will notice that the definitions of the accessor functions are > rather complicated, especially `erc-get-setting'; this is because it is > necessary to handle a large number of specific cases separately, and I > do not believe there is any elegant way of doing it. Using a hash > table to store the settings (instead of a list) would greatly simplify > the definitions; but it is not clear that a sufficient number of > settings will be stored in this system that a hash table would be more > efficient. Hash tables are not necessarily less efficient than lists. And, if as you say, it would increase code simplicity, I think it might be preferable to use them (especially since we don't support emacsen without hash tables). > I also use a case-insensitive string to specify the network rather than > a symbol. I believe this is a better way of doing things. > Anyway, next on my list of stuff to tackle is `erc-macs.el'. Perhaps > before integrating it `victim' should be replaced with `member', or > specifically, `erc-victims' changed to `erc-global-members' and > `erc-channel-victims' changed to `erc-channel-members'. Conveniently, > the existing code uses the unqualified name `channel-members', and so > there is no conflict. > ; car -> var > ; cadr -> value > ; caddr -> network > ; cadddr -> target ick ick ick :), I'd suggest defaliasing some functions, all in the name of data transparancy. (defalias 'erc-set-var 'car), etc... Alternately, in the looping functions, you could use LOOP's destructuring capabilities: (loop for (var value network target) on erc-settings do ...) OTOH, you may not be a fan of LOOP :). I wonder also if your approach would lend itself to SETFable functions. e.g. (setf (erc-settings-get (foo bar "baz")) '(...)) Which would be nice. -- lawrence mitchell <we...@gm...> |