From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Dave Gibson Subject: Multiple Type Interfaces Date: 1997/01/28 Message-ID: <32EE352A.167EB0E7@cis.ohio-state.edu>#1/1 X-Deja-AN: 212800034 references: <6PE5zLpF3RB@herold.franken.de> cc: dgibson@cis.ohio-state.edu content-type: text/plain; charset=us-ascii organization: The Ohio State University Dept. of Computer and Info. Science mime-version: 1.0 newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk,comp.object x-mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Date: 1997-01-28T00:00:00+00:00 List-Id: >From another very long thread: > > There are subtle differences between 'type', 'interface', and 'class' > > and the terms get used somewhat interchangebly around here. They are used interchangebly by some and with completely different meanings by others. In general, 'type' and 'interface' are not used with precisely defined meanings outside of the context of specific programming languages. > I think these differences are mostly artificial. They have been introduced > to capture subtle differences in the way languages implement various > concepts. > > To my understanding, a class is a piece of program code, and an interface > (or type) is everything that one must know to use that class. So an > interface is a set of routine signatures and maybe class invariants, > routine preconditions and routine postconditions. Here's another view. A type is a name for a mathematical set of values or a name for a programming language- and environment-specific set of values. For formal reasoning about program behavior, it is convenient to model `program types' by purely `mathematical' types. An interface describes the externally-observable elements of a component which consist of a structural signature and behavior (ideally explicitly specified). In general, an interface may include any number of types. A class is the common name for a programming langauge component in some OO langauges where it defines a programming language type, an interface, and may include other elements not part of the interface. I am curious about "inheritance-like" relationships between components which export multiple types. Languages like Ada, Modula 2, ML, and others, support component interfaces that may include zero or more program types. It seems like it should be possible to define behavioral substitutability relationships between such components. For example, if component A "includes" all of component B's interface, then component A should be behaviorally substitutable for component B in some informal sense. This seems reasonable to me independently of whether component B's interface includes zero, one, or more types. When Ada83 evolved into Ada95, the concept of multiple type components (packages) survived, but was excluded when it came to OO-style (extendable) tagged types. Clearly packages exporting multiple tagged types would not fit the common OO model in which the concepts of "class" and program type are tightly coupled. Nevertheless, why not define a language so components can export multiple types which may be extended in other related "derived" components? Was this ever considered? Was it just not considered the OO way by Ada95 language designers? Perhaps it would be extremely complicated to implement with little perceived gain. I'd appreciate any comments on this topic. Dave -- dgibson@cis.ohio-state.edu