This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
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