For the record, uiop has a general (but not extensible) accessor called access-at. lisp-interface-library has an extensible interface function lookup — and yes, it works both on alist and on plist (if you supply an appropriate interface object).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The shipwreck survivor's law: after a catastrophe, only the few survivors erect votive shrines to thank deities for having saved them. The many casualties don't erect anti-shrines to spit their contempt at the same deities that failed to save them.
On Thu, Feb 4, 2016 at 2:25 PM, Steve Haflich shaflich@gmail.com wrote:
<silly_question> Does it work for plists? For alists? </silly_question>
Can the user write methods to add his own structures/classes/constructs to the set understood by REF?
More seriously, this function seems to me to be an over generalization, distorting CL style. Built into the numerous built-in ways of supporting data in CL are assumptions about the efficiency and scaling of the various kinds. Although efficiency might not matter for particular low-bandwidth operations, in other places it will certainly matter. That's obvious. But even more important is that use of an over-generalized reference operator makes the code harder to read and understand. If I see an aref, I know I'm looking at an array, understand something about the expected performance, and know what to look for elsewhere in a huge module to examine where this array is constructed and modified.
For me, traditional CL operators have a nice, time-tested balance between generality and specificity.