Re: guile-1.5.1 and deprecated ...

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> Using `(export foo)' in module (b) would be wrong, since (b) does not
> contain a definition for "foo".  You could use `(re-export foo)' to
> make the "foo" from (a) visible to users of (b).  Whether to do this
> is a matter of interface design.  I would find it plausible to require
> users to use the (a) module if they want to use one of the protocols
> associated with the classes defined by (a).

I suppose whether or not this is OK depends on how you think about
generic functions.

One naive view would be that as long as two methods signatures don't
conflict, they're not the same method and there shouldn't be any
shadowing problems.  i.e. imagine you have:

    (define-module (posix))
    (define-method (open (fd <integer>)))
    (export open)

    (define-module (kitchen))
    (define-method (open (x <jar>)))
    (export open)

In one sense, these two definitions and export don't conflict at all
since they operate on completely different data types, and the kitchen
author might not really think they should have to worry about other,
unrelated definitions of "open".  i.e. should the conflict checking be
on the method-name level, or the method-signature level?

I suppose you could require a more specific export.

  (export (open (fd <integer>)))

or perhaps an "export-method" would be appropriate.

In any case, if we don't change anything, I suspect that the
assumption that the conflict checking is at the method-signature level
may be common one, so we at least need to make sure our expectations
are well documented.

I wonder what CLOS does?  I thought it only had problems (not even
sure if it checks for overrides) if you defined two things with
conflicting signatures.  If so, that'll make clear documentation even
more important.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD