🚀 go-pugleaf

jubo@rwthi3.informatik.rwth-aachen.de (Juergen Boerstler) writes:

>Right, if you assume inheritance=subtyping!

I was very careful not to use the word "inheritance".  Subtyping is
what is important when you are trying to plug components together.
Inheritance is useful for making new kinds of components, which is
a different problem.  I was talking only about subtyping in the last
message, not inheritance, because they are not equal.

>In "designing" this way you will loose control over your "architecture",
>since most of the dependencies you introduce are not explicitely visible in
>your interfaces. Ok, there are a lot of tools that help (e.g. browsers), but
>to find the places of interest (i.e. which methods are executed) is a mess.

I don't agree.  The whole idea is to talk at the level of interfaces,
not to have to look at the code with a browser.  How can you say that
most of the dependencies are not visible in the interfaces?  If not,
then what is an interface?

>>Common interfaces eliminate the need for module interconnection languages.

>This is a definite NO!! How do you want to define common interfaces without
>a common (module interconnection) language? 

I guess we have different definitions of a MIL.  I do not consider an
interface description language to be a MIL.  Thus, I don't consider the
OMG DDL to be a MIL.  It is just a language independent type system.
I think of a MIL as being something like Jim Purtillo's (from Maryland)
system, which not only describes the interfaces, but describes how to
convert from one interface to another.

>>A MIL is way of hooking components together even when they do not have
>>similar interfaces.  You still have to do a bit of work to connect them.

>How is this different from "... put a Wrapper around ..." (see above)?

Well, wrappers don't convert interfaces.  They produce something that
has the same interface that we started out with.

>>A great example of a standard interface is the electric system.  In the
>>U.S., all houses have 110 volts 60 hz current, and a consumer can buy
>>appliances from any store, hook them into any house, and they all work.
>>The consumer doesn't have to know very much about electricity, other than
>>things like "you have to plug an appliance in before it will work" and
>>"don't stick a fork in the wall socket".  An engineer designing a toaster
>>(i.e. someone designing a new component) has to know a lot about 
>>electricity, but the average consumer (i.e. someone useing the component)
>>does not.  EXACTLY the same is true of software.

>And exactly to communicate the important aspects of such things is the essence
>and purpose of MILs (module interconnection languages). Your common interface
>is useless, if the consumer does not know what "you have to plug an appliance
>in before it will work" means.

There are at least two levels of meaning to an interface like "American
house current".  One is the meaning known to an EE.  The other is the
meaning known to my mother.  My mother doesn't know anything about volts
or frequency.   She just knows that she can connect a plug into a
compatible socket.  EVERYBODY in the country knows what "you have to plug
an applicance in before it will work", that was my point.  You don't
have to know ANYTHING about the details of the interface to use it.

What this means in a software system is that we shouldn't have to know
anything about the details of an interface except its name.  We should
only have to know that we need a FOO, not what operations are legal on
a FOO.


Ralph Johnson -- University of Illinois at Urbana-Champaign