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