paj@mrcu (Paul Johnson) (07/11/90)
In article <JWG1.90Jul9174438@bunny.gte.com> jwg1@gte.com (James W. Gish) writes: ...... [Quoted argument from mitchell@community-chest.uucp (George Mitchell) about components being re-used without alteration] >This may be what we need, but with the possible exception of very >general pieces of code, I don't think we're going to get very much of >it. It is far too difficult as a designer/coder to envision how your >code is going to be used in the future, either its context or the >exact requirements imposed on it..... >I have done a fair amount of programming in Eiffel over the past year >or so. I like the language a lot. ISE, the suppliers of the Eiffel >compiler, claim to provide a library of reusable classes. The folks >at ISE have put a lot of work into the classes in an attempt to make >them reusable. I've put a lot of hours into trying to use many of >these classes. In many cases, in particular the graphics classes, it >has been a difficult and time-consuming experience. Part of the >problem is with the documentation, but even if the documentation were >perfect, a fundamental problem exists: the designers had a particular >model of computation, a particular style, a particular context, a >particular application in mind when they put together these classes. >Unfortunately, my model, my style, my context and specifically my use >of these classes didn't exactly match what was provided. I am also an Eiffel programmer who likes the language (Note: I have no other connection with ISE) and I would like to argue with you about this. I agree with your comments on the ISE graphics classes: they seem to have been hacked together for the "GOOD" browser (which isn't: I use the Curses one). Extensions are difficult, partly because too much low level stuff for them is written in C (I find this worrying: it seems like any time Eiffel does something difficult and interesting, you find it implemented in C: perhaps this will be fixed in Eiffel 3.0. I see the need for SOME C to underlie the implementation, but Eiffel 2.2 seems to contain a great deal more than necessary). I disagree with your comments about re-use in general. It may be difficult for an author with a particular application in mind to envisage all possible uses for a proposed re-usable class, but I do not think it impossible to arrive at a reasonable subset. My own mental attitude when designing re-usable classes is to imagine that I had found the proposed class in a library and ask: what facilities would I expect it to have? IMNHO the emphasis for a re-usable class must be on the concepts it supports, not on the implementation or the currently envisaged application. When the need for a class or class framework within a project is identified, the design of that class or framework should become a separate project. Meyer writes of extracting and brushing up classes after an application is finished. I disagree, and I think that the Eiffel graphics library is an example of what happens when this approach is employed. None of this should be taken as Eiffel bashing, or even ISE bashing, and certainly not Meyer bashing. Eiffel is an excellent language and ISE and Dr. Meyer are to be complimented on it. Its just the approach to class design that I don't like, and I feel that some parts of the library reflect what I see as mistakes. Paul. NOTE: I am crossposting this to comp.lang.eiffel so as to give Dr. Meyer a chance to see it and reply. If you do follow up, please consider which group(s) should see your article. TNX. PJ. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
bertrand@eiffel.UUCP (Bertrand Meyer) (07/13/90)
From <558@argus.mrcu> by paj@mrcu (Paul Johnson): > > Meyer writes of extracting and brushing up > classes after an application is finished. What I wrote was, I hope, somewhat more nuance'. The observation to which Mr. Johnson refers is descriptive rather than prescriptive: many good reusable components have evolved from more specialized ones through a process of generalization. If you can write components that are reusable right from the start, then great. But an ``existence proof'' is required: you cannot be sure that a component is reusable until you have shown it to be at least usable. If the component's initial avatar was as an element of a specific but reasonably successful system, it has passed that first test - certainly not a sufficient condition, but a necessary one. The comment also has a more practical side. To develop good reusable components, it is certainly better to have as your official charter the development of reusable software components. Most people, however, work in a context where managerial concerns are more short-term; the decision makers want to see working programs more than they want to see high-quality reusable components. This is what (in published discussions of these topics) I have called the traditional ``project culture'', as opposed to the ``component culture'' fostered by object-oriented techniques. Since most people work in an environment where the project culture is the dominant one, the more modest approach to reusability - building up reusable components from specific ones, as opposed to more ambitious efforts having reusability as their avowed goal - may be the only practical one. I have seen it work quite well. I agree with Mr. Johnson that its success requires the designer to have a mental model of future component usage which goes beyond the original application. The only way to validate this model is to apply the components successfully to two or more widely different applications. -- -- Bertrand Meyer bertrand@eiffel.com