rentsch@unc.UUCP (02/12/87)
In article <277@figaro.STANFORD.EDU> asente@figaro.UUCP (Paul Asente) writes: > In article <741@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes: > >Q: 'Can Stack( mixed types ) be written, without using either > > subtypes or parameterized types?' > >OBJ2: no. Smalltalk: yes. > This has been bothering me for some time. In addition to claiming the > ease of programming without having to specify types, advocates of > totally untyped systems (like Smalltalk) always dredge up the example of > having a queue (or stack or list...) that allows arbitrarily mixed > data to be enqueued. In all my years of programming I have never wanted > to do anything like this. I'd be interested in hearing from > > 1) anyone who had needed to do this or something similar > 2) anyone who thinks doing this is good programming style, or > 3) anyone who can come up with a better example of why unconstrained > polymorphism is a good thing in a language. Your objection is well taken. To tell the truth, Stack( mixed type ) is not the best example of Smalltalk-style polymorphism; it is just the easiest one to explain in a short message. To see a better example, see the chapter on Object Oriented Programming Languages in "Fundamentals of Programming Languages" (listed under Ellis Horowitz, Computer Science Press). Code is given for an expression tree which evaluates when sent the message 'value', and so leaves of the expression tree can contain (among other things) Blocks with arbitrary Smalltalk code. The fact of use of the message 'value', allows quite useful flexibility of the "types" of objects stored in the tree. And, although not usually useful for Stack, Collections of mixed classes do come in awfully handy in actual code. The important thing is the ability of an object of one class to masquerade as an object of a quite different class (the "usual" class of objects in the collection). For example, suppose in the current Smalltalk system you wanted your own user interface mechanism, completely independent of the MVC (model-view-controller) approach Smalltalk uses internally. (We have a project here in exactly that situation, for reasons of portability to non-Smalltalk systems.) So, you don't want to use the most abstract superclass Controller. But, you DO want to schedule that class using the existing scheduler, so your applications can run along with the usual Smalltalk browser, debugger, etc. In this case, the collection which holds the scheduled controllers must be able to accept an object which is not a Controller; otherwise, you are stuck. As to whether this is good programming style, well, it CAN be. Just like programs which use only IF and WHILE can still be terribly unstructured, so programs which "mix-and-match" types in a "typeless" language can be structured -- it depends on how it is done. In practice, mixing of types in Smalltalk does not present much of a problem in terms of writing code that works ('Message not understood' errors are among the easiest to fix, typically). The difficulty comes in understanding what kind of objects are expected as parameters -- more a conceptual problem than the "syntactic" problem of which messages to respond to. [Sorry if this is a little too Smalltalk-ish to be understandable.] Research is being done in this area, but in the meantime we have to rely on the old standbys -- aesthetics and program comments. On typeless, or untyped, languages: Smalltalk does not have type declarations, but the very resiliant encapsulation provided by classes and message sending makes Smalltalk seem more "typeful" than many "strongly typed" languages. ["Strongly typed" is in quotes because such languages often are not as completely strongly typed as they would have us believe.] I feel much safer trying a "dangerous" thing in Smalltalk than in even a very strongly typed language like Pascal. So, which is more typeful? Something to think about.... Finally, a meta-comment (and not meant to be disparaging in any way). It is not surprising to me that "In all my years of programming" you have never wanted to use mixed type collections. Until you have it, it is hard to appreciate it -- I went through the same thing myself. Until I had it, I never wanted garbage collection. Until I had it, I never wanted a "typeless" language. Until I had it, I never wanted incremental compilation. But now I have had all three, and I can't imagine NOT wanting them. So, bad as it is, give Smalltalk a try -- you may be surprised. Hope this helps. And, if I may say so, keep those thoughtful postings coming. cheers, Tim
preston@felix.UUCP (02/18/87)
To type or not to type... (sorry) :-) It would seem that what we want is a different notion of 'type'. When you say that 'my set of XXX routines will handle any class of objects as long as they respond YYY and ZZZ methods' then you have given a specification of a (more abstract) type. This is perhaps a 'type specification' that can match any number of actual types (or classes). (For some reason is sounds an awful lot like something I've read elsewhere...) ======================================== Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister