Re: guile-1.5.1 and deprecated ...

[Thomas Wawrzinek]

Hi!

address@hidden wrote:

 > from an appl. devel. point of vue, there should be no difference for a
 > developer between:
 > 
 >      1. defining 2 classes in the same module, with one accessor
 >         bearing the same `name' (and exporting it) 
 > 
 >      and
 > 
 >      2. having these 2 classes defined in different modules
 > 
 > with a 3d module using either the first solution either the second, or
 > both, don't you think? 
 > 

Yes, I think so. 

CC: address@hidden, address@hidden, address@hidden,
        address@hidden
In-reply-to: <address@hidden> (message from David Pirotte on Thu,
        23 Aug 2001 11:46:46 +0200)
Subject: Re: guile-1.5.1 and deprecated ...
References: <address@hidden>
                <address@hidden>
                <address@hidden>
                <address@hidden>
                <address@hidden> <address@hidden> <address@hidden> 
<address@hidden>
--text follows this line--
Hi!

address@hidden wrote:

 > from an appl. devel. point of vue, there should be no difference for a
 > developer between:
 > 
 >      1. defining 2 classes in the same module, with one accessor
 >         bearing the same `name' (and exporting it) 
 > 
 >      and
 > 
 >      2. having these 2 classes defined in different modules
 > 
 > with a 3d module using either the first solution either the second, or
 > both, don't you think? 
 > 

Yes, I think so. Because

address@hidden wrote:

 > By using the `:select' option of `:use-module', you can import the two
 > variables without a name conflict.

You can do so, but I believe there are cases where you don't want
to. Imagine a higher order function that is defined in terms of generic
methods, a (similar) case Java's interfaces were designed for. This should
work with generic methods from different modules too, IMHO.

Requiring the libraries to sort of inherit a common protocol layer adds
complexity and/or dependencies. Especially weird if the libraries and higher
order function are all from different sources (programmers, vendors, whatnot
...) 

Something else:

I've played around a bit with Marius' last example.

    (define-module (protocol-foo)
      :use-module (oop goops))

    (export foo)

    ;; Calling `(foo OBJ)' displays OBJ prefixed by a string
    ;; determined by the type of OBJ.
    ;;
    (define-generic foo)

    (define-module (a)
      :use-module (oop goops)
      :use-module (protocol-foo))

    ;; Make vectors speak the foo protocol.
    ;;
    (define-method (foo (o <vector>))
      (display "VETCOR: ") (display o) (newline))


    (define-module (b)
      :use-module (oop goops)
      :use-module (protocol-foo))

    ;; Make lists speak the foo protocol
    ;;
    (define-method (foo (o <list>))
      (display "LIST: ") (display o) (newline))

I need to tell my main module to use the protocol interface:

(define-module (main)
  :use-module (oop goops)
  :use-module (protocol-foo))

(foo #(1 2 3))
(foo '(1 2 3))

Normally, I don't want to know about lower level features to get module A
running. Worse, I have access to some of the functionality of A and B
without explicitely requiring them. To me, this seems a violation of the
encapsulation principle intended by the use of modules.

The more I think of it (and the dim perception of the underlying
implementation of generic methods and module system I have), the more I
understand that people ran into trouble discussing this a (long?!) time
ago. 

Regards,

                        Thomas