guile-devel
[Top][All Lists]
Advanced

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

Re: Possible bug with re-export, :select and GOOPS accessors?!


From: Thien-Thi Nguyen
Subject: Re: Possible bug with re-export, :select and GOOPS accessors?!
Date: Thu, 30 Aug 2001 13:09:09 -0700

   From: Marius Vollmer <address@hidden>
   Date: 22 Aug 2001 21:23:51 +0200
   
   Can you try the patch below?  If it works for your, I'll apply it.
   It gets the variable from the public interface of the module instead
   of from the module itself, which ought to be the right thing.
   
sorry to jump in late here, but i disagree...  it's better to keep
`resolve-interface' and the "exported interface" conceptually separate
since the exported interface is but one of an infinite set of interfaces
that the user may choose.  certainly, the interface a user chooses *can*
be the exported interface, but it can also be a subset or a superset, or
even a completely disjoint set.  if we don't allow this flexibility in
interface design, people will kludge:

for example, in (ttn gap-buffer), user-level definitions are exported.
intimate module (ttn edit) uses these and also other definitions which
it knows (by some internal contract, hence "intimate") to be available.
previous to this change, it was possible to use `resolve-interface' (via
top-level `use-modules') to elegantly access a custom interface, but now
w/ the change, we have to add this code:

(defmacro FROM-INSIDE:gb args
  `(let ((m (resolve-module '(ttn gap-buffer))))
     (for-each
      ;; similar to (ice-9 boot-9) `resolve-interface'
      (lambda (bspec)
        (let* ((direct? (symbol? bspec))
               (orig (if direct? bspec (car bspec)))
               (seen (if direct? bspec (cdr bspec))))
          (module-define! (current-module) seen (module-ref m orig))))
      ',args)))

note that it re-implements the programming interface of
`resolve-inteface' (since that's what we were happily using before),
certainly a step backwards.

so, i think we should synthesize the original general functionality and
the specific requirements of `re-export', and modify `resolve-interface'
to check first the exported set, then the module's set, and then throw
error on failure:

                     (or (module-local-variable public-i orig)
+                        (module-local-variable module orig)
                         (error

also, the error message should not worry about "exported" or not since
`resolve-interface' has no business enforcing this restriction and is in
fact, provided to enable custom interface design.

if no-one objects, i will do this change shortly.

thi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]