Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!wnv!lhn!mdlcpgs From: mdlcpgs@lhn.dsir.govt.nz Newsgroups: comp.lang.modula2 Subject: Re: Op overloading/var. parms Message-ID: <8024.28252688@lhn.dsir.govt.nz> Date: 6 May 91 09:48:56 GMT References: <8015.280c0c0e@lhn.dsir.govt.nz> <1991Apr19.173651.9572@iitmax.iit.edu>, <8020.281425b4@lhn.dsir.govt.nz> <4c7263c91EAfQ1BW4G@rchland.ibm.com> Organization: DSIR GEO, Lower Hutt, N.Z Lines: 30 > I agree that overloaded operators can be nice. However, they also can > be easily abused. A popular one is to use + for string concatenation > "'cause it's just like you're adding the two strings together." Well, > you aren't adding them you are concatenating them. If "ab" + "cd" is > "abcd" then 123 + 456 must =be123456, right? :-) Dont get this. "123" + "456" would indeed equal "123456" 123 + 456 = 579 A compiler is in real trouble if cant distinquish types. The parsing of this as I see it is: without op overloading a := "123" + "456" should result in error message. with op overloading and + redef imported from string module then compiler uses the + redefinition when it discovers a,"123" and "456" are strings. > > And as for complex numbers, if you have a good compiler that allows any > type to be returned as a function result then: > > a := Complex.Add(b,c); > > is much clearer than your example (though in this case still not as nice > as a:=b+c). Better but what is status of structured returns in the proposed standard while we are about it? Phil