johnson@p.cs.uiuc.edu (11/16/89)
dwiggins@atsun.a-t.com asked "What should a component library look like"? In particular, he said "It seems to me that separation of functional specification from implementation is at least a Good Thing, if not absolutely necessary for a viable library. This would allow a variety of implementations that meet the spec, and that vary in their performance details (memory, speed, language, operating system, etc.)." This is a very common claim. I disagree with it. This is only important in a library of data structures, which will eventually be a minor part of component libraries. Take a user interface library, for example. There is no need to have a variety of implementations that meet the spec. I think that data structure components are the exception rather than the rule. Most of the code that we write is not heavily dependent on algorithms, and so performance will not be a big deal. Specifications are important because they help the potential reuser to understand the component. Thus, they are very important. However, I don't buy the idea that we will need lots of implementations that meet the same spec. And yes, I've read Booch's "Software Components with Ada". It is all about data structures. Ralph Johnson -- University of Illinois at Urbana-Champaign
johnson@p.cs.uiuc.edu (11/17/89)
dwiggins> what is the role and task of the "software component librarian"? billwolf>To manage an interface between component producers and component users. I'd like to argue this point. The interface between component producers and users should be designed and managed by the component producer. As in the rest of life, producers are in business only as long as they satisfy their customers, i.e. the users, so it should go without saying that producers must communicate a lot with users and should base their designs on the needs of users. However, I think that design should be done by as small a group as possible, and we certainly don't need intermediaries like a "librarian" who is neither a domain expert or a technology expert. It is possible that I am misinterpreting "manage". I see the role of a librarian as making sure that components have documentation and test suites, that they can run their test suites, etc. The purpose of the librarian is simply to reduce the chaos that would happen if everybody could add and delete components from the library on their own. If you only have a dozen people, it might not be worth the effort to centralize that task. On the other hand, if you rely a lot on component libraries that you get from other places then it might be necessary to have someone in charge of getting new versions and installing them, even if your group is smaller. I think the orginal question was whether it was worth it to invest a lot of time and money in a good component library. Absolutely! The problem is in getting good components. You should certainly grab from the net those that you can get from free, but I'm skeptical that this will ever amount to much. It is probably in your best interest to develop your own domain-specific components and to buy domain independent ones. Building good reusable components is much more difficult than most people let on, but they are worth the trouble. In case I have not made myself clear, the question of which components are needed, whether to buy or build them, which versions to buy, etc. are NOT the responsibility of the librarian. These questions are crucial, and must be the responsibility of high-level technical and management people. Perhaps you see a librarian as one of those people. The name means something different to me. billwolf> Another problem is the existence billwolf> of languages which are not standardized and for which no compiler billwolf> validation capability exists. This is completely bogus. There is a great deal of reuse in Smalltalk, which is not standardized and which has no standard compiler validation suite. This is just propaganda for Ada. There has been a huge amount of effort put into Ada reuse. There are only a couple of Smalltalk venders, and they are all small and poorly funded. Nevertheless, Smalltalk users all enjoy a high degree of reuse, but Ada programmers only do if they work at it. As far as I am concerned, Ada is no more conducive to reuse than C. Good programmers can write reusable components in C. They can in Ada, too. However, I wouldn't say that either language PROMOTES reuse.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/17/89)
From johnson@p.cs.uiuc.edu: > dwiggins> what is the role and task of the "software component librarian"? > billwolf> To manage an interface between component producers > and component users. > > I'd like to argue this point. The interface between component producers > and users should be designed and managed by the component producer. [...] > It is possible that I am misinterpreting "manage". I see the role of a > librarian as making sure that components have documentation and test suites, > that they can run their test suites, etc. The purpose of the librarian is > simply to reduce the chaos that would happen if everybody could add and > delete components from the library on their own. If you only have a > dozen people, it might not be worth the effort to centralize that task. This assumes that everyone can unilaterally decide to produce components which are large enough to justify reuse, which is contradictory to the assumed software engineering methodology. In order to reduce the chaos which would result if everybody could create components on their own, each required component is identified in the detailed design phase and the librarian provides information regarding the match (or lack thereof) between the component requirements and the component supply. If components are required which are not immediately available, then the librarian decides how to acquire the component, either by producing and validating it locally or by acquiring it on the open market... normally the latter will be the preferred strategy, but there may be special factors which dictate otherwise. > In case I have not made myself clear, the question of which components > are needed, whether to buy or build them, which versions to buy, etc. > are NOT the responsibility of the librarian. These questions are crucial, > and must be the responsibility of high-level technical and management > people. Perhaps you see a librarian as one of those people. The name > means something different to me. The librarian should not be in the business of deciding which components are needed, but should be in the business of deciding whether to buy or build, which versions to buy, etc. > > Another problem is the existence of languages which are not > > standardized and for which no compiler validation capability exists. > > There is a great deal of reuse in Smalltalk, which is not standardized > and which has no standard compiler validation suite. If it's not standardized, then there are portability problems. If there are not portability problems, then it's standardized. > As far as I am concerned, Ada is no more conducive to reuse than C. > Good programmers can write reusable components in C. They can in Ada, > too. However, I wouldn't say that either language PROMOTES reuse. This is like saying that since it is possible to write bad code in any language, no language promotes the writing of good code, or that since all programming languages are Turing-equivalent, they are all equally useful. Face the facts: some languages are better at promoting reuse than others, e.g., Ada relative to C. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/17/89)
From johnson@p.cs.uiuc.edu: > In particular, he said "It seems to me that separation of functional > specification from implementation is at least a Good Thing, [...] > This is a very common claim. I disagree with it. This is only important > in a library of data structures, Then it's at least a Good Thing, right? Furthermore, domain-specific packages will define domain-specific data abstractions, for which once again we encounter the need to separate specification from implementation. Thus, the separation is important regardless of the type of code reused. > Most of the code that we write is not heavily dependent on > algorithms, and so performance will not be a big deal. Most of the code that YOU write, maybe... but you're in a Smalltalk "experimental programming in the small" environment. Since the programming is experimental, performance is not a major issue; since you are programming in the small, the fact that Smalltalk does not provide any separation of specification from implementation does not create communication problems among the hundreds or thousands of programmers who would have to interact if you were programming in the large. For software engineers doing programming in the large, the separation of specification from implementation is absolutely essential. Hopefully, the ideas of Wilf LaLonde regarding programming via exemplars (in which there are separate inheritance lattices for specification and implementation) will eventually result in the development of object-oriented systems which are more suitable for programming in the large. > Specifications are important because they help the potential reuser > to understand the component. Thus, they are very important. However, > I don't buy the idea that we will need lots of implementations that > meet the same spec. And yes, I've read Booch's "Software Components > with Ada". It is all about data structures. Then read Booch's "Software Engineering with Ada", and discover how the separation of specification from implementation can apply equally well to reuseable subsystems. Bill Wolfe, wtwolfe@hubcap.clemson.edu
snorri@rhi.hi.is (Snorri Agnarsson) (11/20/89)
From article <7096@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > ... Hopefully, the ideas of > Wilf LaLonde regarding programming via exemplars (in which there are > separate inheritance lattices for specification and implementation) > will eventually result in the development of object-oriented systems > which are more suitable for programming in the large. Sounds interesting -- do you have references? Snorri -- Snorri Agnarsson | Internet: snorri@rhi.hi.is Taeknigardur, Dunhaga 5 | UUCP: ..!mcvax!hafro!rhi!snorri IS-107 Reykjavik, ICELAND
dwiggins@atsun.a-t.com (Don Dwiggins) (11/21/89)
In article <7095@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
This assumes that everyone can unilaterally decide to produce
components which are large enough to justify reuse, which is
contradictory to the assumed software engineering methodology.
^^^
In order to reduce the chaos which would result if everybody
could create components on their own, each required component
^^^^^^^^
is identified in the detailed design phase and the librarian
^^^
provides information regarding the match (or lack thereof)
between the component requirements and the component supply.
The highlighted words imply a particular scenario for the library and the
software development environment that it's imbedded in. I can envision a
number of reasonable organizational and procedural arrangements that would
lead to different degrees of "coupling" between the producers, librarian,
and consumers. Could you elucidate your assumptions in the above statement?
Having made this request, I guess it's only fair to expose the model that
I'm assuming. I'm thinking of a software development organization that
produces "products" (where the consumers may be outside customers or
internal users), and has several projects going on at once (some of which
may be related). Rather than having a separate group of "component
producers", components would be produced as spinoffs of normal development
activity. This would, of course, involve some overhead (from the point of
view of the project manager) to either plan or retrofit the desired
qualities into the component. I'm not advocating this as the only way to
go, but it seems like a reasonable initial goal for a multi-project
organization.
Unfortunately, I haven't received Johnson's message, and I'd rather not
comment on an excerpt out of context, but I will say that having more than
one implementation for a given spec can be useful for more than performance
reasons (portability to radically different environments, for example).
--
Don Dwiggins "Solvitur Ambulando"
Ashton-Tate, Inc.
dwiggins@ashtate.a-t.com
dwiggins@ashtate.uucpdalamb@qucis.queensu.CA (David Lamb) (11/23/89)
From johnson@p.cs.uiuc.edu: > In particular, he said "It seems to me that separation of functional > specification from implementation is at least a Good Thing, [...] > This is a very common claim. I disagree with it. This is only important > in a library of data structures, Separation of functional specification from implementation is the most widely-perceived example of separation of properties guaranteed not to change from properties allowed to change. The typical examples are all from data structures, but the principle is more general. The separation gives the implementor and maintainer free to change things without having to rewrite lots of the rest of the system. Parnas has examples of device drivers, for example, where you need to write most of the software for a system before the engineers have pinned down the last detail of the hardware interface to the radar. The "abstract interface" for the radar device includes functional specifications, but also any other assumptions the device driver needs to make about its clients and vice-versa.
craig@gpu.utcs.utoronto.ca (Craig Hubley) (11/25/89)
>(William Thomas Wolfe, 2847 ) writes: > > This assumes that everyone can unilaterally decide to produce > components which are large enough to justify reuse, which is > contradictory to the assumed software engineering methodology. > ^^^ Generally, reusable components must be more reliable than those intended to be used once - more effort must be put into making them *correct* and creating *robust* versions (two different things!). The additional resources to do this should probably be allocated centrally, on a priority basis, by someone with organization-wide responsibility. > In order to reduce the chaos which would result if everybody > could create components on their own, each required component > ^^^^^^^^ Re-use is an incremental thing. Casual re-use implies that a piece has been *found* that is useful. Organized re-use implies that a piece has been designed to be reusable. Both kinds require a central registry for reusable or potentially reusable code. A set of simple metrics like 'how many projects has this been used in' is probably a good starting point for determining 'how' reusable something is. There is also the issue of whether a class/library designer should be required to support a class for the use of others, or whether that responsibility should pass to the central registry. > is identified in the detailed design phase and the librarian > ^^^ > provides information regarding the match (or lack thereof) > between the component requirements and the component supply. Don't forget that the librarian should be looking *first* for appropriate libraries outside the organization, presumably produced and maintained by those whose primary business is producing and maintaining *that* library. To do otherwise is to dilute effort into areas others have already covered adequately, and diminish the value-added of one's own product. The same organization-wide position should be responsible for purchasing libraries from outside, or commissioning their development into reusable code inside. >The highlighted words imply a particular scenario for the library and the >software development environment that it's imbedded in. I can envision a >number of reasonable organizational and procedural arrangements that would >lead to different degrees of "coupling" between the producers, librarian, >and consumers. Could you elucidate your assumptions in the above statement? Since I've butted in on this :-), I should at least explain my own assumptions: 1. Central registry and resources for reusable software are crucial. Word of mouth is not adequate publicity, and casual change/fix requests are not adequate support for reusable code. 2. If reusable code emerges from a project not specifically oriented towards producing it, that is a nice coincidence, but if code is to be supported across more than one project that must be a concious decision - other decisions, such as to buy that particular functionality for later projects, are certainly possible and must be considered carefully. A lot of resources can be consumed making code correct and robust. Someone must be made responsible for supporting the code in its new, general, role, and resources must be available for that - at first, very substantial resources, as the culture of re-use has to be built and encouraged. 3. 'Correct' code responds correctly to correct input. 'Robust' code responds predictably to incorrect input. 'Robust' versions of code can be derived from 'correct' versions, as they retain the same interface and only add some error-checks. The two versions can then be used interchangeably as the situation demands. Usually both must be available for real reusability. 4. In larger organizations (more than 10 people!) a microcosm of the larger set of roles can be mirrored for projects or groups of projects. Someone may be responsible for searching the organizational code resources for items useful in the current project. Someone else may be responsible for specializing these. The central registry may decide if the specializations, or any new code generated, should be included in the organizational resources. This may sound bureacratic but it's the way other forms of information resources are re-used in organizations (legalese, business letters, insurance policies, etc.) >Having made this request, I guess it's only fair to expose the model that >I'm assuming. I'm thinking of a software development organization that >produces "products" (where the consumers may be outside customers or >internal users), and has several projects going on at once (some of which >may be related). Rather than having a separate group of "component >producers", components would be produced as spinoffs of normal development >activity. This would, of course, involve some overhead (from the point of >view of the project manager) to either plan or retrofit the desired >qualities into the component. I'm not advocating this as the only way to >go, but it seems like a reasonable initial goal for a multi-project >organization. The danger with this should be clear by now - the project manager is not being encouraged or rewarded to design good reusable code - quite the opposite. His/her project deadlines and costs are being impacted by an activity that he/she has no resources or incentive to support. Planning and retrofitting are both time-consuming activities, and when you consider that the interface to the basic code facilities of the project are the first bottleneck any project runs into... A useful alternative would be to identify certain key projects as likely to produce large portions of reusable code. These should not be projects that are business-critical or have tight deadlines. Ideally, they should almost be 'optional' or 'CEO pet projects' with low consequences for failure. A group of people ready to risk some prestige for the sake of getting involved with a new technology, perhaps a group with something to prove or make up for, might make the best team. It should be emphasized from the beginning that the degree to which their work is re-used will be a crucial factor in evaluating the project - perhaps more so than the final result. All of this should be visible to the team from the beginning. This group may later become your corporate component library. Without such projects available, another possibility would be to create a group to work with project managers and designers in the early stages of *all* projects. Such a group would need expertise in every application area that the company works in, because they would need to evaluate the potential for re-use of every piece of code produced by every project. With their help, the project manager should be able to define interfaces early enough to stay on deadline. For co-operating, some incentive such as increased administrative resources (for those extra phone calls!), longer deadlines (if a project can't come in two weeks later to serve a major long-term goal, your company is already in trouble), conference/training support, or even some fun money (an interesting excursion at the organization's expense). In any case, it is necessary to back up the corporation's interest in this long-term goal with some visible support. The more visible the better. >Unfortunately, I haven't received Johnson's message, and I'd rather not >comment on an excerpt out of context, but I will say that having more than >one implementation for a given spec can be useful for more than performance >reasons (portability to radically different environments, for example). Essentially the 'correct' vs. 'robust' distinction is two implementations on what is really the same spec (most specs don't include error recovery). I agree that the inheritance matrix is an implementation mechanism, and if I could build a separate one for the users (of my library) to see, I would. The functional relationships may not be identical to the implementation matrix. >Don Dwiggins "Solvitur Ambulando" >Ashton-Tate, Inc. Craig Hubley ------------------------------------- Craig Hubley & Associates "Lead, follow, or get out of the way" craig@gpu.utcs.utoronto.ca ------------------------------------- craig@gpu.utcs.toronto.edu mnetor!utgpu!craig@uunet.UU.NET {allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig craig@utorgpu.bitnet -- Craig Hubley ------------------------------------- Craig Hubley & Associates "Lead, follow, or get out of the way" craig@gpu.utcs.utoronto.ca ------------------------------------- craig@gpu.utcs.toronto.edu mnetor!utgpu!craig@uunet.UU.NET
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/26/89)
From dwiggins@atsun.a-t.com (Don Dwiggins): > I can envision a number of reasonable organizational and procedural > arrangements that would lead to different degrees of "coupling" between > the producers, librarian, and consumers. [can you clarify assumptions?] My assumptions were essentially a production environment, but I would certainly be interested in hearing about these different arrangements you visualize relative to the degree of coupling. > I'm thinking of a software development organization that produces > "products" (where the consumers may be outside customers or internal > users), and has several projects going on at once (some of which may be > related). Rather than having a separate group of "component producers", > components would be produced as spinoffs of normal development activity. Under my scenario, this would occur whenever the component librarian determines that it would be more efficient to produce a component locally (rather than purchase it on the open market). The work order would then go out to an engineer for production; generally if a series of similar components are to be produced, related work orders would be routed to the same location. This assumes, of course, that a requirement has already been established for a given component. From the passage, I infer that you may be talking about producing components simply because the production costs are low due to the existence of related work. This is where the librarian and the reuse community must confer during the evaluation of the marginal production cost and the anticipated future value, the latter being an extremely difficult quantity to assess accurately. Where component production orders are approved, it is extremely important that a) the marginal production costs be tracked separately and NOT billed to the customer, and b) these production costs are closely monitored by the librarian along with the usage benefits, in order to develop heuristics which will maximize the cost-effectiveness of such decision-making. One of the heuristics most likely to be productive in this respect is to follow closely the research stemming from what I consider to be a landmark paper on the topic: "Domain Analysis -- From Art Form to Engineering Discipline", by Guillermo Arango of UC-Irvine's Advanced Software Engineering Project. It's on pages 152-159 of ACM SIGSOFT Software Engineering Notes, Volume 14, Number 3, May 1989 -- I heavily recommend it to any and all readers of this newsgroup. Bill Wolfe, wtwolfe@hubcap.clemson.edu [ P.S. -- Ralph Johnson and I are having an interesting discussion of specification vs. implementation topics via e-mail, and I would like to publicly apologize for the strong tone of my initial reaction to his article. It was not initially apparent to me that he supported the general principle of separating specification from implementation, so I shall include a bit of crow in all of my turkey sandwiches!!! :-) ]
johnson@p.cs.uiuc.edu (11/26/89)
Since several people have misunderstood my position, I guess I didn't describe it very well. I am strongly in favor of separating specification from implementation as much as possible. My complaint was against the claim that one of the main reasons for separating them was so that each specification could have a set of implementations, each of which had different performance characteristics. My observation is that, except for general purpose data structures, there doesn't seem to be much need for a component to have a variety of implementations that vary in performance characteristics. In my opinion, the idea that specification whould be separated from implementation is a "motherhood" issue that needs no defense. I am arguing against a particular use of this idea, not the idea itself. Part of the problem comes from different meanings of "specification". I most certainly do NOT use the Ada notion of an interface specification. That is just type conformance. Since I push polymorphic languages, i.e. object-oriented languages, I naturally think that it is essential to have many components with the same type. However, I think of "specification" as defining the behavior of a component, not just barely enough to type-check programs. As an example, object-oriented user interface systems usually assume that each object can display itself and can respond to actions by the user. Thus, each user interface object has a "display" and a "mouse clicked" operation. If you consider the set of operations that an object will perform to be its specification, then all the user interface objects have the same specification. However, menus respond quite differently from buttons to mouse motion and mouse button presses. Thus, I'd say that they have completely different specifications. I'd consider two objects to have different specs if they looked at all different on the screen. Thus, different kinds of menus would have different specifications, although they would look pretty much the same to the application program, and one could easily be replaced by another. Ralph Johnson
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/27/89)
From article <130200023@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu: > I am strongly in favor of separating specification from implementation > as much as possible. [...] My observation is that, except for general > purpose data structures, there doesn't seem to be much need for a component > to have a variety of implementations that vary in performance characteristics. > [...] I think of "specification" as defining the behavior of a component Okay, let's talk about that. Suppose that we have a application entity whose behavior is defined by a specification. We must now be very careful with respect to what we mean by this. Traditionally, this has meant that all behavior is defined EXCEPT performance behavior such as time and space consumption (tradeoffs) among the various operations. If we define a specification such that it completely specifies the behavior of a component, UP TO AND INCLUDING component performance characteristics, then there is clearly little need to have a variety of implementations. Assume otherwise, i.e., that the term "specification" does not include performance characteristics. Consider an application entity -- not a general-purpose data structure, but an object associated with the application domain. Different applications having different performance interests may well emphasize different operations over that application entity. Surely we would not wish to introduce redundancy by having several different definitions of the same object; we would instead wish to factor out the commonality of the shared specification. Nor would we wish to have a single definition that has to be rewritten (at great cost) every time it is used or every time we wish to regenerate a particular application. Furthermore, it may well be the case that we wish to have, within a single application, particular instances of an object whose performance characteristics differ but which are otherwise interchangeable (e.g., as parameters to a subprogram which requires that type of object). If we accept the basic premise that performance characteristics are an important consideration, then I think it follows that there is a fundamental need to express the existence of different implementations. Bill Wolfe, wtwolfe@hubcap.clemson.edu
weide@elephant.cis.ohio-state.edu (Bruce Weide) (11/30/89)
Bill Wolfe's most recent note about the need for specifications is right to the point. On the off chance that another explanation of the same issue might help a few readers... Suppose specifications describe only functional behavior, not performance behavior, of components. Then it does seem natural and valuable to factor out the commonalities among various implementations and specify a single ABSTRACT component's functional behavior in a single place (which many of us have called its specification). Clearly, a reusable component might have multiple implementations in this view of the world of "components." Perhaps what's causing some confusion on this point is that everyone doesn't seem to share this notion of what a reusable component is. If you think an IMPLEMENTATION is the focus of reuse -- the main thing being reused -- then you might be tempted to think component specifications should include performance information and that each implementation should have separate specs (of both functionality and performance behavior). Bill and I and many others have been proceeding on the assumption that the ABSTRACT functional behavior is the focus, the abstraction the main artifact to be reused. It serves as the specification for many possible implementations precisely because it doesn't tie down performance. Implementations are also reused, but only by virtue of being correct ways of achieving the required abstract functional behavior. In fact, they should be interchangeable in a client program from the standpoint of correct functional behavior of the client. Different implementations will, of course, generally not have the same performance for all the services provided by the abstract component, and indeed should not, as Bill eloquently points out. -Bruce
kamin@m.cs.uiuc.edu (12/01/89)
I'd like to repeat a point made by Ralph Johnson in an earlier notestring that I think is very important. In a sense, I believe that Ralph and the other respondents are thinking of different things when they say "specification." Namely, there is a kind of specification *between* "abstract, functional" spec. and "performance" spec. There is a spec. that includes the abstract, functional behavior *and* explicitly gives its dependence on the spec.'s of the functions it calls. The reason this distinction is important is that in reusing code in object-oriented languages, it is this latter kind of spec. that is needed. If you are talking about a data type (but non-oo) language, then "reuse" means "being a client of", or "calling". This kind of reuse exists also in o-o languages, but the interesting kinds of reuse are those you get by redefining methods *and thereby changing the semantics of other methods you use.* Thus, we need a specification that not only says what a method m does, but says how your redefinition of some other methods will alter what m does. (One way to think of this is that each method has all the other methods it calls as implicit arguments; the specification must give the meaning of the method as a function of *all* its arguments, including the implicit ones.) In principle, this is just an "abstract, functional" spec., but in practice it is a much more complicated thing. I believe that Ralph's earlier point about programs as specifications might be restated as "You are unlikely to find that a spec. in this o-o sense will be significantly simpler than the code." This has some bearing also on the current argument about multiple implementations of a single spec. I think Ralph is saying that in his experience in Smalltalk, this doesn't happen much. However, what *does* happen a lot is that a class is inherited and modified (by subclassing). In other words, in this context, one has a spec. (if at all), not in order to give multiple implementations that vary in *performance*, but rather to give multiple implementations that vary in *semantics*. Of course, from a traditional specification viewpoint, this last assertion is nonsensical - if the semantics are different, it is, by definition, *not* an implementation. Still, I believe this is the basic philosophical position that Ralph is coming at this thing from, and perhaps this may help dispel some confusion. Sam Kamin Univ. of Illinois at Urbana-Champaign
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/01/89)
From kamin@m.cs.uiuc.edu (Sam Kamin), who clarifies things considerably: > we need a specification that not only says what a method m does, > but says how your redefinition of some other methods will alter > what m does. [...] In principle, this is just an "abstract, > functional" spec., but in practice it is a much more complicated thing. > [...] This has some bearing also on the current argument about multiple > implementations of a single spec. I think Ralph is saying that in his > experience in Smalltalk, this doesn't happen much. However, what *does* > happen a lot is that a class is inherited and modified (by subclassing). > In other words, in this context, one has a spec. (if at all), not in > order to give multiple implementations that vary in *performance*, but > rather to give multiple implementations that vary in *semantics*. Thank you, Sam!!! OK, now that we have established what it is we are discussing... :-) I for one have never seen ANY discussion of this type of specification anywhere, although it is intuitively obvious that o-o languages will require this sort of "specification", and it would certainly appear to be high time that somebody HELD such a discussion. Has any work been done regarding the ins and outs of writing & using these specifications? It might be interesting to see a few examples which present the general idea and demonstrate how complications can arise. Also, a few comments regarding the integration of this new type of specification into the traditional framework would be interesting... Since the *.uiuc.edu folks proposed this departure from the traditional specification/implementation paradigm, hopefully they are in a position to open the discussion. If we can get a good handle on this type of specification, then I think we will be well on the way to integrating o-o techniques and components into software engineering environments. Bill Wolfe, wtwolfe@hubcap.clemson.edu