This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 contain all messages, not just those from before July 7th, 2015.
On 4/14/06, Per Bothner <per@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