Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-modula-2 From: wyant@APOLLO.UUCP (Geoffrey Wyant) Newsgroups: net.lang.mod2 Subject: Re: extensions, a modest proposal Message-ID: <8603040446.AA04991@uw-beaver.arpa> Date: Mon, 3-Mar-86 08:15:08 EST Article-I.D.: uw-beave.8603040446.AA04991 Posted: Mon Mar 3 08:15:08 1986 Date-Received: Wed, 5-Mar-86 04:08:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 48 I would like to reply to Mr. Keller's comments on overloading: I'm going to agree w/ Rob Nagler on this one, even though I think his example was poorly chosen. ........... > With overloading, controlled generic capability can be achieved. > Why would anyone want that? Well, would you want to have to distinguish > between + for integer and + for reals? Would you want to have to > invent unique names for each procedure that did an equivalent thing > to its data type? This is just the problem with overloading. It provides a superficial veneer of polymorphism over what are essentially different procedures. If 2 procedures do the same thing and only differ in the data types they take, why should I have 2 invent 2 different procedures ? True polymorphism would allow you to write only a single procedure. If the 2 operations differ subtley (or even not so subtley) in their semantics, I would claim that it is poor software engineering to allow them to be named the same thing. > I see nothing wrong with Mr. Nagler's example. In fact, I like it > because I wouldn't want to have to remember to use (say) PUT-ARRAY > instead of PUT. Again this instance, the PUT procedure shouldn't be overloaded, but should be able to accept parameters of any type, provided said parameter provides a "write" operation. > If done at compile-time, you can use compile-time expansion as if the > generic package were a macro with macro conditionals. In some sense, > overloading without generics can be thought of as a limited collection > of macro expansions of the generic that used macro conditionals. Macro expansion of types is the wrong way to think about type parameters. It fails to allow for recursive types among other things. Well, not that any of this has anything to do with Modula-2, and I'm not proposing that M2 should be made polymorphic. I just believe that overloading is a knee-jerk approach to polymorhism, and the semantic underpinnings fail to generalize in any sort of usefull fashion. ---------------------------- Geoff Wyant -------