From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fa18fb47ddd229a7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-11 07:24:38 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Proposed change to BC iterator parameters Date: 11 Dec 2003 10:24:37 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1071156277 1452 192.74.137.185 (11 Dec 2003 15:24:37 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 11 Dec 2003 15:24:37 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:3374 Date: 2003-12-11T10:24:37-05:00 List-Id: "Steve" writes: > "Robert A Duff" wrote in message > news:wccekvc2rol.fsf@shell01.TheWorld.com... > [snip] > > > > I don't understand the point of Param_Type and Param above. If you want > > to pass extra information to Apply, nest the instantiation in a place > > where it can see that data. > > The reason for Param_Type and Param is to avoid using data outside of the > scope of the Apply routine except for the arguments to the Apply machine. > It comes from that old school of thought: > Avoid global data > All inputs and outputs of a procedure should appear in their parameter > lists > > Following these simple guidelines usually makes code a lot easier to follow. The data we're talking about is not *very* global. It's local to the procedure containing the instantiation. Yes, it's global to the actual procedure passed to Apply, but that's probably a pretty small region of code. This seems like a lot of mechanism for little if any gain. Consider what you have to do if you want to pass *two* parameters. You have to wrap them in a record type, fill in the record fields, extract them out. Seems verbose and error prone, to me. Do you really follow the above guideline *strictly*? It seems to me a useful guideline in many cases, but there are many cases where it would be damaging. For example, consider a package that behaves like what Lisp calls "symbols". The Intern routine puts a string in a hash table, and returns a unique identifier of that string (so if you Intern the same thing twice, you get back the same identifier). Then "=" can be extremely efficient. But it doesn't work if you have more than one hash table. So the right thing is to put the hash table in the package body -- not allow clients to choose which table to pass to Intern. - Bob