[893] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next last

Re: [COLD] Operator overloading

daemon@ATHENA.MIT.EDU (Wed Jan 10 16:59:11 1996 )

From: Jettero Heller <heller@grail.cba.csuohio.edu>
To: coldstuff@tombstone.sunrem.com
Date: Wed, 10 Jan 1996 16:35:30 -0500 (EST)
In-Reply-To: <Pine.BSF.3.91.960110134045.12925E-100000@tombstone.sunrem.com> from "Brandon Gillespie" at Jan 10, 96 01:46:28 pm
Reply-To: coldstuff@tombstone.sunrem.com

> > I don't have the new source on me, but in 2-10, there's 
> [snip]
> > for addition. So, cthrow could be replaced with the method call on the
> > first argument (I don't feel like rummaging through the source to find
> > the exact recipe. :) ) Brandon, can this be done?
	[ snip ]
> However, I'm unsure as to the overall benefits, in general you would be 
> creating more work for the driver (since it is not designed for operator
> overloading), with the only benefit being more readable (yet abstracted)
> code... 

Personally I've never been one to make much use of operator overloading.
I think it's only marginally more readable. Onlu if the designer did
a good job at deciding how the overloaded operator should act. One 
example of this is the list example you gave:

[1, 2, 3] + 1;

that doesn't really mean much to me. Is the result:

[1, 2, 3, 4]  
or 
[1, 2, 3, 1]

I usually discourage use of operator overloading for exactly this 
reason. What is meant by it is often quite unclear. Granted the
programmer himself may know what he means, but chances are few other
people know. I've seen overloaded operators abused to often. 

Just my two cents worth on the operator overloading issue. 

** Heller

-- 
"I think the Exon amendment should at least require that AOL spay its 
users before they're allowed out to play."  -- Usenet post
Can you imagine having an implant so the government can track you anywhere
you go? It's coming and we're bringing it to you, AT&T.