[Erc-help] Re: Changes/fixes in erc-nets.el

[lawrence m. <we...@gm...>]

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...>