This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Wishlist questions



> > > * easy to import and re-export entire interfaces (so that a main
[...]
> The GOOPS module exports a set of bindings. STKlos [...] wants to export
> all bindings in the public interface of the GOOPS module except for a
> few which it want to replace.

> I don't want to list each binding in the GOOPS public interface also
> in the STKlos compatibility module.

Agreed.  [Reminder for me: Check if it makes sense to implement module
          inheritance: a module M' may not only `open' a module M but
          "inherit" from it by extending the interface of module M -- if not
          we need first class signatures even for scheme modules]

> the user doesn't need to write a long list of interfaces to use each
> time he writes a program using OOP) we then need a way to merge all
> subsets of bindings into one interface.  
[...]
> Furthermore, when implementing replacements for "standard"
> functionality in the GOOPS interface, the STKlos compatibility module
> needs to access "internal" bindings in the (oop goops) module. 

Doesn't the following do what you want?

* support module collections: "packages" with a package scope for
  people working together on a project.  In some sense a module is a
  view on the underlying package.

* ability to request (i.e. import or access) complete packages.



> * easy to import and re-export entire interfaces (so that a main
>   interface in a package can function as a "relay" and publish
>   bindings from many modules in the package)

>> > Can you please explain what interfaces are and why interface
>> > types(!) are useful?
>> 
>> First I must ask you why you think I'm talking about types and in what
>> sense, since I can't remember talking about it in the letter you reply
>> to.  

I've asked because I don't want to separate the module's interface
from the module implementation.  Eiffel is a very old language and has
been used to build huge software systems.  Until now it doesn't
support signatures.  In fact, a signature is just the poor man's
version of a class.  Signature inheritance is less powerful than class
inheritance.


> For a large program, it's not the code but the interfaces between
> modules which is the central and most important part of the design.

I disagree.  You can mix the module's meta information (extends what,
imports from, exports what, ...) with the module code.  The compiler
is responsible for extracting the meta-information.

 scheme-module ----- compiler ----> object code
                              \---> interface



> For example, we might design a database interface consisting of a
> number of variable and procedure names, and possibly type
> declarations.  Then different people might come up with different
> database implementations, but they all support the same interface.

You create a prototype class from which the concrete classes (designed
by different people) can interit.  Because they derive from a common
super-class they have not only the same interface but also a common
structure.


> This basics of this idea is the same as that behind ADT:s

Got me. :)  What are ADT's?




> The reason why we want to be able to specify types is that compilers
> can use them to do static analysis of a module in order to generate
> maximally efficient code.  

Types yes, signatures no.   I don't think it is a good idea to abuse
a programmer as some kind of pre-processor for the compiler. :)

While compiling P the compiler can get all the meta-information for
module Q just by looking at the interface file of a Q.  -- This
interface file has been created by the compiler itself.

 P.scm ----- compiler ----> P.obj
                      \---> P.interface 
                                        |
 Q.scm ----- compiler ----> Q.obj        |  (references Q)
                      \---> Q.interface <





> > > * support re-use of code (the same implementation can be presented to
> > >   the world through several interfaces)
> Let's take the database situation again: Let's say that there are two
> branches of development of applications with databases out there.
> Neither branch knows about eachother until time T.  Then people from
> the extraordinary application A discover the excellent database used
> from application B.  Team A might then persuade team B to implement
> and publish an A family interface in their database code.  This works
> as an adapter so that code from both the A and B family can use the B
> database.

Hmm.

           Common
           /    \
          A     B  (inherit from Common)
           \    |
             \  B' (inherit from A and B)

Customers can use B' which implements both A and B functionality.
This is called "repeated inheritance", not "multiple inheritance"
btw.  Repeated inheritance means that all slots inherited from
Common will be merged in B'.


> Another example concerns backward compatibility: One might want to be
> able to publish different revisions of the same interface in
> developing code so that both old and new users can be supported
> simultaneously.

Should the new and old version be available simultanously or
should the old version only be available to "old" customers?


Jost

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]