Xref: utzoo comp.object:3737 comp.lang.misc:8030
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.object,comp.lang.misc
Subject: Re: bashing BASIC (Was: Functions without side effects)
Keywords: functionality
Message-ID: <72952@microsoft.UUCP>
Date: 17 Jun 91 19:09:00 GMT
References: <130242@tut.cis.ohio-state.edu> <4888@osc.COM> <72893@microsoft.UUCP> <1991Jun14.082204.1997@jyu.fi>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 39

[actually, was: bashing Set/Get]
[I think Basic is just like Smalltalk, only more so :-]

In article <1991Jun14.082204.1997@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>In many cases it would be quite sensible to go even further:
>	somepart = object.part();
>	object.part() = somepart2;
>I.e. make the member function (instance method) 'part' return a _reference_.
>Or even make the data member (instance variable) 'part' visible to clients,
>i.e. get rid of those parentheses.  This _is_ as commitment that restricts
>later modifications of the class definition, but in return it makes
>the semantics clearer to client programmers.

I partially disagree.  There is great concern in the C++ community that
providing such direct access restricts implementation choices of future
evolutions of that class, but I don't see that as a major issue -- to
have a usable class one must commit to *some* interface, and that interface
is always going to restrict what one does in the future.

However, where I disagree is in the idea of encoding too many details
of the meaning of a method into the exact syntax used to invoke that 
method.  I don't believe end users find such fine-grained distinction
helpful.  Rather, they just find it difficult and confusing trying to
remember the "right" syntax to invoke a given member function / variable.
So I believe interfaces should be designed to [as best as possible]
only use one syntax style, [namely the function-like style]:

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

with parameters and return types chosen to minimize the number of extra
'&'s, '*'s, '()'s etc. required when invoked in a "typical" manner.
I believe simplicity is generally the greatest contributor to clarity.
Code with lots of noise words, mixed caps, mixed syntax, zillions of
operators, etc, reads like crap.

[In this regard I would have been happier if C/C++ allowed one to 
 skip the '()' null parameter list -- but this issue was decided for
 us many years ago.]