Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.object
Subject: Re: Functions without side effects (was Old confusion)
Keywords: functionality
Message-ID: <72893@microsoft.UUCP>
Date: 13 Jun 91 17:55:57 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <327@alfrat.uucp> <1991Jun3.145924.28406@mstr.hgc.edu> <130242@tut.cis.ohio-state.edu> <4888@osc.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 79

In article <4888@osc.COM> jgk@osc.COM (Joe Keane) writes:
>Some people would name either or both of these methods just `part', perhaps to
>save keystrokes.  I think this indicates a confusion between a method and the
>value it returns.  Here is the way i see it: `widget.part' is an attribute,
>`widget.get_part()' is a method call which returns the part, `widget.part()'
>is a mistake since you're trying to call an object, and `widget.get_part' is a
>method which would return the part if you called it.

I disagree.

Once upon a time there was a language called "Basic" that used a '='
for both assignment and equality testing.  Fearful that some beginners
might find this confusing, the language authors introduced the "let"
noise word:

	LET part = somepart;

However users of the language recognized that this was silly and 
redundant and chose not to use the noise word.

Nowadays some "object oriented" library writers introduce the "set" and
"get" noise words for fear, as in Basic, that the users of the libraries
might otherwise get confused.

However users of these OOP libraries recognize that this is silly
and redundant and choose not to use the noise words.

----

Thus I claim:

"Get" and "Set" are object oriented for "Let"

----


I recommend:

Please allow C++ compiler's strict type checking and overloading by parameter
type to do their jobs.  It is unnecessary and redundant for *first* the 
programmer and *then* the compiler to encode type information in function
names:

	object.ObjectDoSomething();	// please don't encode class names
					// in method names -- the compiler
					// already does this for you!

	object.DoSomethingWithInt(100);	// please don't encode parameter types
					// in method names -- the compiler
					// already does this for you!

	somepart = object.GetPart();	// please don't encode return types
	object.SetPart(somepart2);	// or lack thereof in method names --
					// the compiler already performs 
					// selection based on parameter type!

Without redundant noise words this becomes simply:

	somepart = object.part();
	object.part(somepart2);


Note: for the above functions the compiler generates "type safe" mangled
names that if re-written in plaintext might be something like the following:

	Object__ObjectDoSomething__void
	Object__DoSomethingWithInt__int
	Object__GetPart__void
	Object__SetPart__Part

verses:

	Object__part__void
	Object__part__Part

[ Further, the above proposed form without the Let, Set, Get noisewords
  allows rapid prototyping via overloaded operator(), if so desired ]

[my opinion only]