Alex Shinn wrote:
> * OOP purist - "Just wrap any parametric behaviour into one or more
>   configuration objects."  This is very flexible, and convenient for
>   chaining and passing on the same (or slightly modified)
>   configuration to other functions.

For example some GUI APIs have "style objects": A style is a
possibly-named possibly-modifiable possibly-inheritable mapping
from keys (symbols or property specifiers) to property values.
Many "widgets" can share a common style.

>   The disadvantages of this are that either 1) for every parametric
>   procedure you need to define a new class and keep it in sync as
>   the API changes, or 2) you use a single extensible configuration
>   class, perhaps a hash-table or closure, which suffers from poor
>   performance.

But this isn't really any different or worse than using a-lists or
p-lists or for that matter the proposed CL-inspired solution.  It's
an implentation tradeoff between constant-type lookup versus compact
size.  (Worth considering is a sorted "property vector".)

Even if functions are defined in terms of configuration object, one
would still want nice syntatic sugar that maps into configuration
objects.  That is somewhat easier if we view a configuration object
as a list of "associations" - which may or may not be the same thing
as a traditional a-list.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/