abbott@aerospace.aero.org (Russell J. Abbott) (09/01/89)
Since *anything* can be an object there is nothing to prevent one from building processor objects that parallel traditional subprograms. For example one could define a SquareRoot class whose instances would be objects with a single defined method squareRoot: aNumber. SquareRoot new squareRoot: 4 would return 2. Is there an argument against this style of programming? I notice that in st80, there are processor objects, e.g., the scanner. An advantage is that it reduces the clutter that results from putting every kind of operation into data objects. That is, one is not stuck with defining squareRoot as a method inside numbers when one doesn't always need numbers that can take their own square roots. Of course if one uses this approach, one's code is likely to look somewhat more like traditional code. In fact, couldn't any traditionally coded program be translated into an object oriented language in this way with virtually no structural change? -- -- Russ abbott@itro3.aero.org
sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/01/89)
In article <57069@aerospace.AERO.ORG> abbott@itro3.aero.org (Russell J. Abbott) writes:
-
-Since *anything* can be an object there is nothing to prevent one from
-building processor objects that parallel traditional subprograms. For
-example one could define a SquareRoot class whose instances would be
-objects with a single defined method squareRoot: aNumber.
-
- SquareRoot new squareRoot: 4
-
-would return 2.
- ...
You don't need _instances_ at all to accomplish this kind of thing:
define "squareRoot" as a _class_ method so you can simply say
SquareRoot squareRoot: 4
Or define a "MathFunctions" class that has both "squareRoot"
and other class methods.
Disclaimer: I am not a Smalltalk expert,
apologies if this is a standard way of programming
that almost everybody in the ST community uses when appropriate.
Lynn Stein's paper, "Inheritance Is Delegation" (OOPSLA'87),
makes one realise that classes (that is, ordinary classes,
not metaclasses) are the most important and most powerful objects
in Smalltalk-80.
Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland
fchan@vlsi.waterloo.edu (Francis Chan) (09/02/89)
In article <57069@aerospace.AERO.ORG> abbott@itro3.aero.org (Russell J. Abbott) writes: > >Since *anything* can be an object there is nothing to prevent one from >building processor objects that parallel traditional subprograms. > <stuff deleted> >Of course if one uses this approach, one's code is likely to look >somewhat more like traditional code. In fact, couldn't any >traditionally coded program be translated into an object oriented >language in this way with virtually no structural change? Yes, I have done something similar (a large rug so I can sweep the dirt under it, anyone?). But this was due to a time pressure thing and I didn't want to redesign much of the code. This was not a significant piece of code but still... It has been redesigned and recoded since.. but yes traditional programs can be ported with little or no structural change. However, you gain almost zero advantages given to you by the object oriented environment since the traditional style of coding gives little thought towards something else using its methods or the possibility of having subclasses. i.e. reusability is essentially down the drain. >-- Russ abbott@itro3.aero.org Francis Chan
johnson@p.cs.uiuc.edu (09/04/89)
Russ Abbot asks about classes that model procedures, not abstract data types. The best discussion I know on the topic is by Dan Halbert and Pat O'Brien in the September '87 edition of IEEE Software. It is called "Using Types and Inheritance in Object-Oriented Programs". One thing to note is that by "type" they mean class. In my opinion, a type is very different from a class, but that is about our only point of disagreement. In general, operations should be implemented as methods, not as classes. However, there are several places where it is reasonable to make them classes. One is where the operation is very complicated, were there are many ways to implement it, and where these implementations have a great deal of internal structure. For example, "compile" can be thought of as a method in class String that returns a compiled procedure, but nobody would ever do that. Compilers are complicated, and usually contain parsers, symbol tables, code generators, and many other parts. It is much more reasonable to make a Compiler class that represents an instance of an executing compiler. Smalltalk-80 does this. However, users almost never deal with the compiler directly, but instead ask classes to compile a string and install it as a method. The class will instantiate a compiler to do all the hard work, so we end up with both an elegant interface to the compiler and a nice design for the compiler. Another place where it is reasonable to implement an operation as a class is where you will want to reuse that operation for many classes, many of which are not closely related. For example, you might want to sort any kind of sequentiable collection, though contents of the collection have to have a comparison operation. Moreover, there are many different kinds of sorting algorithms, and it seems a bit odd to put every single one in the same class. It is probably better to define a Sorter class and to define the "sort" method as Sorter sort: self. If a particular sorting algorithm is needed then you can easily call it. Implementing operations as classes is the exception, not the rule. You should only do it when the alternative is worse. However, there are times when it is the best option. Ralph Johnson - University of Illinois at Urbana-Champaign
kasper@iesd.auc.dk (Kasper Osterbye) (09/06/89)
In article <80500073@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > >Russ Abbot asks about classes that model procedures, not abstract >data types. The best discussion I know on the topic is by Dan Halbert >and Pat O'Brien in the September '87 edition of IEEE Software. It is >called "Using Types and Inheritance in Object-Oriented Programs". >One thing to note is that by "type" they mean class. In my opinion, >a type is very different from a class, but that is about our only point >of disagreement. > >In general, operations should be implemented as methods, not as classes. >However, there are several places where it is reasonable to make them >classes. [Stuff deleted] > >Implementing operations as classes is the exception, not the rule. >You should only do it when the alternative is worse. However, there >are times when it is the best option. > >Ralph Johnson - University of Illinois at Urbana-Champaign In the Beta language they have unified methods and classes in a single construct called patterns. This seems to be the right way to solve this specific problem (or at least one way). For an introduction to the Beta language one can see ECOOP 88, or Wegner et al. "Research directions in Object oriented programming". One of the interesting aspect of this unification is that one gets inheritance for "methods" as well as for classes (Discussed in a paper at ECOOP 87 I believe). Kasper Osterbye, Aalborg Universitycentre, Denmark. -- Kasper Osterbye Internet: iesd!kasper@uunet.uu.net Institute for electronic systems UUCP: ...!mcvax!iesd!kasper Strandvejen 19, 9000 Aalborg DENMARK. (W) +45 98 13 87 88-285 (H) +45 98 37 30 65