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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: Charles Hixson Subject: Re: Software landmines (loops) Date: 1998/09/06 Message-ID: <35F238F7.F57D3EC7@earthlink.net>#1/1 X-Deja-AN: 388352460 Content-Transfer-Encoding: 7bit References: <6qfhri$gs7$1@nnrp1.dejanews.com> <35cb8058.645630787@news.ne.mediaone.net> <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <6sebjr$b69$1@nnrp1.dejanews.com> <6sfcse$78h$1@hirame.wwa.com> X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: Sun Sep 6 00:23:18 1998 Organization: Mandala Fluteworks Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-06T00:00:00+00:00 List-Id: Matthew Heaney wrote: > ... > The flag makes it _much_ harder, because it doubles the number of rules > in the decision table. Is THAT why! O. I knew that it made the code more difficult to understand, but I hadn't ever connected it with a decision table. And someone said earlier that adding an internal if-branch added an edge to the directed-graph (?), so I guess that if you use an if test on a flag to get around executing part of the code on the first/last pass, then you are adding both complexities (or are they different ways of saying the same thing? But somehow pulling chunks of code into a function and then calling that function makes things simpler, even though the flow of execution follows the same path, so something else is going on here. I tend to think that one of the major activities of programming is properly "chunking" the problem into pieces that have low-bandwidth connections with the rest of the code. This is what made the FORTRAN COMMON blocks such a bad idea, they didn't cut down the bandwidth. There is, of course, more to it than that. Anonymous blocks that occur in the middle of code may actually be isolated in just the manner that a called routine would be, but they aren't "visually isolated" and this makes it difficult to model them as isolated chunks. As a result of this analysis, I feel that Java's Anonymous inner class construct is a very bad idea. On the other hand, a named internal class would be a good idea. It could even have exactly the same meaning (including even [ugh!] read/write access to internal class variables). But if it were declared in a visually separated location (c.f., Pascal's internal functions), then it would be an means of helping the chunking. Personally, I think that if this were to be implemented, there should be, say, a "sealed internal class" that didn't have access to the internal class variables of the class that contained it. This would help improve the isolation. But almost all of the effect of this can be obtained by just not declaring the class as internal. I just feel that a tightly coupled class that doesn't really have any use outside the context of another class should be declared internal to that class (Ada can manage this by appropriate use of Private, but, to me, it's a rather tricky thing to handle this properly [I'm not sure if one can completely declare a class within the code body of an Ada file, and if you did, I think that it would have full access to the locally declared variables, thus expanding the bandwidth of the interface]).