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

[Jeremy Maitin-S. <jb...@at...>]

lawrence mitchell <we...@gm...> writes:

> Jeremy Maitin-Shepard wrote:
> [...]

> 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)) ?

Well, the advantage to (VAR VALUE NETWORK CHANNEL) is that
(caddr '(VAR VALUE)) is nil (i.e. no special handling needing.  Also,
if you wanted to specify just a network, would it be (VAR VALUE
NETWORK) or (VAR VALUE (NETWORK)) ?  (Both of these would require
special handling, although with accessors it would be a moot point.

In any case, if hash tables are used, this structure would not exist.

>> [snip]

>> 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 do not know exactly the overhead of using a hash table, but the info
documentation specifies that a list with a few tens of elements may be
faster than a hash table.  However, because `erc-settings' is not a
simple alist, and the code to manipulate it is rather complicated, it
may be that a hash table is more efficient.

As far as the code being simpler, it would only affect the code of the
accessor functions, and so that is only a minor point.  A significant
disadvantage with using a hash table, however, is that users would need
to have a bunch of `erc-put-setting' commands in their init files,
rather than a (setq erc-settings ...) command (and the setq command
would be a significantly faster than the hash table commands).

>> [snip]

>> ; 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")) '(...))

When I first wrote the accessors, I used a slightly different
interface, where `erc-setting-get' returned the list of (VAR VALUE
NETWORK TARGET), and I provided setf-able macros to extract the
components.  But then I changed the interface to be compatible with a
possible hash table interface.  With the current interface, the user
has no need for the setf-able macros, so I eliminated them.

If we decide that 1) we don't want to use hash tables 2) it is better
for `erc-get-setting' to return the list of (VAR VALUE NETWORK TARGET)
rather than just VALUE, then I could re-add these macros.

Another idea would be to use a cl struct vector as the entry in
`erc-settings'.  That might be the nicest technique if we want there to
be more of an accessor interface.

I will prototype some of these ideas.

-- 
Jeremy Maitin-Shepard