sakkinen@jyu.fi (Markku Sakkinen) (06/14/91)
In article <72893@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >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. I too disagree with the main point, thus agree with you, but I'm digressing on your analogy. Therefore the cross-posting to comp.lang.misc. >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. It was not silly at all! It was a good and consistent principle in BASIC that every statement began with a verb. I can imagine that it made parsing, error analysis, etc. a lot easier. Especially for a language that was designed to be interpreted, and for the 60's state-of-the-art in language implementation. This pattern has been followed e.g. by SQL -- although it does not matter so much when almost all statements are 'SELECT's anyway. Also, some functional languages have adopted the 'let' convention. The famous FORTRAN error that caused a spacecraft bound for Jupiter to fly astray (or something like that?) could not have happened in BASIC: DO 210 I = 1.100 This further reminds me that BASIC's NEXT loop_variable is the nicest way to end a simple indexed loop that I have seen. [The following is formulated for C++] > ... >I recommend: > ... > > 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); 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. > ... >[ Further, the above proposed form without the Let, Set, Get noisewords > allows rapid prototyping via overloaded operator(), if so desired ] This looked a little cryptic at first. I assume you mean overloading '()' in the class of 'part'. ---------------------------------------------------------------------- "All similarities with real persons and events are purely accidental." official disclaimer of news agency New China Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ----------------------------------------------------------------------
jimad@microsoft.UUCP (Jim ADCOCK) (06/18/91)
[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.]