--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 02, 2006 at 04:26:52AM +0100, joerg@britannica.bec.de wrote:
> On Wed, Feb 01, 2006 at 10:30:29PM +1030, Brett Lymn wrote:
> >=20
> > 1) deregister a hook function after it has run, some of our hooks to
> > this to prevent them being run again.
>=20
> You mean an one-shot modus? I'd say make the hook-removal O(1) with
> small O(1) and it can be implemented completely via a wrapper function.

Yeah, but I thought the whole point of this was to make a common resource
that captures common behavior.  :-) If we know that we want to
remove-after-use all the items on a list, then it seems simpler to have
the itterator do it. We then have one hook-remove call rather than one per
called routine.

> > 2) no reverse traversal.
>=20
> Can you give an example of why this is needed? I can think of situations
> where you want to add a new hook at the end or the beginning of the
> current list, but no need to traverse the list backwards.

Others have spoken about this, and I think the pfil example (assuming
Matt's memory is correct, which I believe) indicates why we need it; at
different times, we walk the list in both directions.

But there's one other reason: that's what the code does now.

By replacing all of our little implementations with one common one that=20
has exactly the same behavior, we can be much more certain that we changed=
=20
everything correctly. If we have to change how subsystems interface (say=20
because they used to walk the chain in reverse and now can't), we=20
_probably_ will get it right, but we might not. Yeah, the chances of=20
getting something wrong are slim, but larger than if we go to an API that=
=20
has the existing behavior.

Take care,

Bill

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFD4jSEWz+3JHUci9cRAtIZAJ0WHXv8BkQPAV+KjcDPEqs9T7MG+QCeK4rT
3Td5vcbqj6hgsuSLJl5AHUY=
=SNCA
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--