Russell,
>I'm not sure I get your point. I don't know if you're poking fun at the minor, insignificant changes that some people want to apply to example code, or if you're making a serious statement. Ultimately, the small changes you made are inconsequential. IMHO, some of them make the routine less obvious. But, as I said, I can't determine if you're serious or not.

this thread was started with quite an emphasis on speedy execution. Your approach via afields() is in best cases one of, if not *the* slowest solutions, and your implementation is evidently not the speediest one. So I rearranged the code a bit to get at least a speedier implementation of the afields()-approach.

What I was making fun of is the part in the commentary reserving copyrights (yes, I guess it was just copied from your sources at work) - similar functions were in the public before 2001 (probably even in the last century<g>) and defining a line between "forbidden copy" and "own implementation" would be hard to argue in view of prior art.

On "inconsequential": as a large part of the thread was on speed, I view speed-ups
twice as large than the baseline for best possible implementation
or
about the same as the overhead of the function(field())-approach
to be not inconsequential. But also, I would not use ANY afields-approach, as there are non-extreme settings were it is not only near/on the bottom speed wise, but also worse than the best implementation by a factor greater than 100.

Such a factor size I do not consider insignificant. This *can* slow down applications if used a couple of hundred times in a FWK-based approach on machines not top of the line. YMMV.

regards

thomas