[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: highly parametric interfaces

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.

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

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
per@bothner.com   http://per.bothner.com/