kearns@cs.columbia.edu (Steve Kearns) (09/13/90)
One of the biggest pains of smalltalk-like classes is that to understand one class may require scanning four or five classes (the inherited ones). This is neccessary to find out all the functions and variables that make up a derived object. This goes against one of the fundamental principles of object oriented programming: a class encapsulates all the functions and data that comprise an object. One solution is to copy the inherited information into the derived class, prefixing the inherited items with the keyword "inherited". This is not really a viable solution, however, since an edit of the super class might require edits in all derived classes. A better solution seems to be the following: soon we will all be using nifty class browsers. I would suggest that these class browsers automatically copy the inherited items (and their documentation, please) into the subclass with the inherited keyword, or else in italics, or prefixed with the superclass name. The benefit of all this, I repeat, is that one would have to look at exactly 1 class to understand 1 class. -steve
d87-mra@dront.nada.kth.se (Magnus Ramstr|m) (09/13/90)
In article <1990Sep13.011214.24799@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes: >One of the biggest pains of smalltalk-like classes is that >to understand one class may require scanning four or five classes >(the inherited ones). This is neccessary to find out all the functions >and variables that make up a derived object. > >This goes against one of the fundamental principles of object oriented >programming: a class encapsulates all the functions and data that comprise >an object. > Correct, but one "class level" defines properties added to, deleted from or replacing properties in the superclass(es). The class consists of this and inherited properties. > >.... >A better solution seems to be the following: soon we will all be using >nifty class browsers. I would suggest that these class browsers >automatically copy the inherited items (and their documentation, >please) into the subclass with the inherited keyword, or else in >italics, or prefixed with the superclass name. > >The benefit of all this, I repeat, is that one would have to look at >exactly 1 class to understand 1 class. This is a good idea, providing that only the documentation and absolutely not the implementation is copied. The subclass has no interest what so ever in the implementation of superclass methods, only the interface. When creating a subclass it is valuable to know what is already implemented. When implementing new methods, there is no differance between messages it can send to super and messages it can send to any object accessible from the method. >-steve /Magnus. d87-mra@nada.kth.se (Magnus Ramstr|m). Student @ Dep. of Computer Science.
johnson@m.cs.uiuc.edu (09/14/90)
The Tektronix Smalltalk browser as of three or four years ago was able to show all the inherited methods of a class. It showed implementation, not just comments, and this was very useful. You can select how much of the class hierarchy should be shown, which is also important. In my opinion, it is proper to show the implementation of superclasses. If you don't want to know the implementation of a class then you should probably be reusing it as a member, not as a superclass. Ralph Johnson -- University of Illinois at Urbana-Champaign
adams@nonvax.alf.dec.com (Vernon Adams) (09/14/90)
In article <1990Sep13.011214.24799@cs.columbia.edu>, kearns@cs.columbia.edu (Steve Kearns) writes: |> One of the biggest pains of smalltalk-like classes is that |> to understand one class may require scanning four or five classes |> (the inherited ones). This is neccessary to find out all the functions |> and variables that make up a derived object. |> |> This goes against one of the fundamental principles of object oriented |> programming: a class encapsulates all the functions and data that comprise |> an object. |> |> One solution is to copy the inherited information into the derived |> class, prefixing the inherited items with the keyword "inherited". |> This is not really a viable solution, however, since an edit of the |> super class might require edits in all derived classes. |> |> A better solution seems to be the following: soon we will all be using |> nifty class browsers. I would suggest that these class browsers |> automatically copy the inherited items (and their documentation, |> please) into the subclass with the inherited keyword, or else in |> italics, or prefixed with the superclass name. |> |> The benefit of all this, I repeat, is that one would have to look at |> exactly 1 class to understand 1 class. Steve, You seem to be missing one of the great boons of object-oriented systems: inheritance. If you COPY stuff from the parent classes to the child classes you lose the inheritance capabilities. Your code is no more mantainable than heavily "included" code from traditional languages. One point of inheritance is that if I do discover a bug in some code and make the fix to that code, the fix will propagate to all the children who inherit the code. However, not to flame, your complaint about limited visibility within a heavily decomposed class hierarchy is a very legimate one. And it has already been addressed in some class browsers. Instead of copying code (or even doc) from the parents of a class, some browsers provide a class flattening mechanism which allows the user to view either only those extensions defined within this class or to view all the inherited characteristics (including mehtods) of a class. By using the second option one can see everything about a particular class and where it was inherited from. Take a look at Object/1 for an example. Hope this helps answer your complaint with smalltalk-like classes. Vernon
noren@dinl.uucp (Charles Noren) (09/15/90)
In article <1990Sep13.061908.1032@kth.se> d87-mra@dront.nada.kth.se (Magnus Ramstr|m) writes: ...a discussion from Steve Kearns on the value of a browser browsing classes... > >This is a good idea, providing that only the documentation and absolutely >not the implementation is copied. The subclass has no interest what so ever >in the implementation of superclass methods, only the interface. When >creating a subclass it is valuable to know what is already implemented. When >implementing new methods, there is no differance between messages it can >send to super and messages it can send to any object accessible from the >method. This is certainly the ideal, however there are many times when the documentation is inadequate. I have browsed the source code in class libraries in other languages and found it extremely valuable. It helps me pinpoint why my software didn't work (do to misunderstanding the documentation) and is a valuable aid in further learning the language and how the class library works. Looking at the implementation certainly violates a cardinal principle of encapsulation, but we don't live in an ideal world (or work enviroment) where there will be complete and perfect information of the interface. -- Chuck Noren NET: dinl!noren@ncar.ucar.edu US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 971-7930
klimas@iccgcc.decnet.ab.com (09/25/90)
In article <1990Sep13.061908.1032@kth.se>, d87-mra@dront.nada.kth.se (Magnus Ramstr|m) writes: > In article <1990Sep13.011214.24799@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes: >>One of the biggest pains of smalltalk-like classes is that >>to understand one class may require scanning four or five classes >>(the inherited ones). This is neccessary to find out all the functions >>and variables that make up a derived object. >> >>This goes against one of the fundamental principles of object oriented >>programming: a class encapsulates all the functions and data that comprise >>an object. >> > Correct, but one "class level" defines properties added to, deleted from or > replacing properties in the superclass(es). The class consists of this > and inherited properties. >> >>.... >>A better solution seems to be the following: soon we will all be using >>nifty class browsers. I would suggest that these class browsers >>automatically copy the inherited items (and their documentation, >>please) into the subclass with the inherited keyword, or else in >>italics, or prefixed with the superclass name. >> >>The benefit of all this, I repeat, is that one would have to look at >>exactly 1 class to understand 1 class. > > This is a good idea, providing that only the documentation and absolutely > not the implementation is copied. The subclass has no interest what so ever > in the implementation of superclass methods, only the interface. When > creating a subclass it is valuable to know what is already implemented. When > implementing new methods, there is no differance between messages it can > send to super and messages it can send to any object accessible from the > method. A bit of advice based on evolutionary Smalltalk history. The kind of functionality you are describing is available in Smalltalk with a thing called a "flattener goody". It basically adds the ability for the Class Hierarchy Browser to show everything inherited by a particular class. Practical experience shows that the use of hierarchy flatteners becomes analogous to being hit in the face with a fire hose. If you get a significant hierarchy, there is so much stuff there at once that it becomes more difficult to work with. Go ahead and implement it but if your experience is anything like we've seen, the usability of the system will go down. That's why most ST users I know who have played with flatteners have abandoned them after a while and why it isn't provided on off-the-shelf Smalltalks anymore.