From: John Cowan <xxxxxx@ccil.org>
Date: Friday, October 25, 2019 11:18 AM
> ((engine-set engine) okvs ((engine-pack engine) string uid)
> ((engine-pack engine) #t))))
Ah, I thought the issue was extensibility. SRFI 128 solves this problem by providing invokers as well as accessors, and in hindsight maybe I should have skipped the accessors. The general pattern is that the short names like engine-set and engine-pack take an engine object as the first argument and apply the appropriate procedure from the object to the other arguments. So the lines above become:
(engine-set engine okvs (engine-pack engine string uid) (engine-pack engine) #t).
There's something I'm missing here, unless you're citing SRFI 128 as an example implementation of the concept you're advocating.
To try to make this clear, answering in part one of Amirouche's questions from another posting, the brute force method I'm initially using for sdbi (but haven't yet coded) would in this engine context look like something like:
(define-record-type OKVS-Engine
(make-engine engine-set-proc engine-pack-proc etc.)
engine?
(engine-set-proc okvs-engine:engine-set-proc)
(engine-pack-proc okvs-engine:engine-pack-proc)
etc.)
(define (engine-set engine-record etc.)
((okvs-engine:engine-set-proc engine-record) etc.))
And would be used something like:
(define the-engine (make-engine (lambda (x) x) (lambda (x) x)))
(engine-set the-engine 1) ==> 1
This only uses accessors, but looking at srfi-128/srfi/128.body1.scm would seem to be an invoker like e.g. comparator-test-type:
;;; Invokers
;; Invoke the test type
(define (comparator-test-type comparator obj)
((comparator-type-test-predicate comparator) obj))
It hides the ugliness from the user of the API, pushing it down to the implementor's level, which I and I gather Amirouche would prefer to eliminate altogether.
[ Accessors, and includes references to record creating SRFIs. ]
- Harold