Path: utzoo!attcan!uunet!netxcom!netxdev!kcr From: kcr@netxdev.DHL.COM (Ken Ritchie) Newsgroups: comp.lang.smalltalk Subject: DIRECT REFERENCE CONSIDERED HARMFUL Summary: Use message passing, not variable reference. No fondling. Message-ID: <1865@netxcom.DHL.COM> Date: 21 Nov 89 18:22:25 GMT References: <28.UUL1.3#913@acw.UUCP> Sender: news@netxcom.DHL.COM Reply-To: kcr@netxdev.UUCP (Ken Ritchie) Followup-To: comp.object Organization: NetExpress Communications, Inc. Lines: 73 =============================================================================== [This was cross-posted to comp.object,comp.lang.c++ initially as a followup...] [I'm offering this as a COMP.LANG.OBJECT thread & recommend we FOLLOWUP THERE.] =============================================================================== In article <28.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: >Do you then wonder what the OO version of [Edsger Dijkstra's] famous "Go To >Considered Harmful" will look like? Yes, Scott... I've wondered... and maybe we just saw it this year... hmmm? Get out your JOOP vol.2, no.1 (May/June 1989) and see pages 34-40. "VARIABLES LIMIT REUSABILITY" -- sounds like a dire pronouncement! Actually... Allen Wirfs-Brock (AWB) and Brian Wilkerson (BW) make a convincing argument against using direct reference to variables -- recommending, instead, that methods ALWAYS be implemented for evaluating/changing state variables. AWB & BW say "Direct references to variables severly limit the ability of programmers to refine existing classes." It probably won't take six years for the follow-up controversy to emerge, but if history has any hints for us, there WILL be lots of dialogue over efficiencies and such.... Perhaps this initial argument will also be extended to prohibit "fondling" (friends accessing private parts). AWB & BW briefly discuss the potential tradeoff of man/machine efficiency. I say we should follow Dijkstra's admonition (1972) to make the most of our limited mental capacities -- rather than fuss over micro-efficiency. [Put your torches away, folks, I KNOW there's a time to split nano-secs!] As a system designer, I've often found it advantageous to design for some distribution of function even if you [initially] cast it all into a monolith. >>> CONSIDER THIS: As soon as you decide you need to distribute an example application across a multi-nodal network system -- local or otherwise -- YOU'LL SUDDENLY BE VERY GLAD YOU DID IT WITH MESSAGES (in whatever language). Except for the speed of light (186Kmi/s - "it's the law") there is virtually no limit to the kind of architectures which will support applications based on message passing models. Besides, in the event of a monolithic or shared storage environment for some application, optimizers could tweak the code. NOTE: Scott's posting was to comp.object and comp.lang.c++, to which I've added comp.lang.smalltalk. For general discussion, I recommend we FOLOWUP-TO: comp.object (only) -- except for language-specific issues. OK? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Regards to all! ...and, as Ed [Berard] would say: "Thanks for listening!" BIBLIOGRAPHY Edsger W. Dijkstra, "The Humble Programmer", CACM 15(10), Oct. 1972, 859-866. [This was an inspiring lecture, given upon receipt of the ACM Turing Award.] [I have heard it on audio-tape, but I don't know if such is available now.] For you history buffs... EWD, "Go to statement considered harmful", CACM 11(3), Mar. 1968, 147-148, & 538, 541. [This is the (in)famous letter to the ACM forum, leading to war!] Donald E. Knuth, "Structured Programming with GO TO Statements", ACM COMPUTING SURVEYS 6(4), Dec. 1974, 261-301. [It's not the goto's or lack thereof...] _______________________________________________________________________________ Ken Ritchie (d/b/a KCR) Usenet: ...!uunet!netxcom!netxdev!kcr c/o NetExpress Communications, Inc. FAX/office: USA (703) 749-2375 8500 Falling Leaf Road Voice/office: USA (703) 749-2268 Springfield, Virginia (USA) 22153-2505 Voice/home: USA (703) 455-7514 "OBJECTS... ARE CLOSER THAN THEY APPEAR" -- inscription from a convex mirror _______________________________________________________________________________