On 4/14/06, Per Bothner <xxxxxx@bothner.com> wrote:
> Alex Shinn wrote:
> >
> >   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".)

With a fixed class-based approach you need to define and make changes
to parameters in two places (borrowing CLOS-like syntax):

  (define-class <number-formatter> ()
     (radix)
     (precision)
     ...)

  ...

  (define (number->string n fmt)
    (with-slots (radix precision) fmt
      ...))

as opposed to only specifying them in the lambda or let formals where
they're actually used:

  (define (number->string n #!key radix precision)
    ...)

If you're using a family of procedures sharing the same options (and
thus the same class) then the procedure and class definition may not
even be near each other.

If you want to use a more general association instead of a fixed
class, then the simpler and more transparent that association is the
better.  With a p-list the association and friendly syntax are rolled
into one, and for the moderate number of parameters typically needed
will likely be faster than a hash-table.

--
Alex