Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #2267
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: A good subset of C |
| Date | 2014-05-19 00:54 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <llbh7e$p4g$1@dont-email.me> (permalink) |
| References | (16 earlier) <op.xf0siais6zenlw@localhost> <ll8jnp$qea$1@dont-email.me> <op.xf03jult6zenlw@localhost> <ll9lp4$9gl$1@dont-email.me> <op.xf2fbp056zenlw@localhost> |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message news:op.xf2fbp056zenlw@localhost... > On Sun, 18 May 2014 02:59:49 -0400, James Harris > <james.harris.1@gmail.com> wrote: >> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message >> news:op.xf03jult6zenlw@localhost... ... >>> But, I'd definately question the sanity of someone breaking apart a >>> sort routine or search algorithm across multiple modules. >> >> Sure. If parts of a routine work in conjunction with each other, operate >> on the same data and use the same structures then keep them together. >> > > Ok, so, you really see Parnas Principles as being applied after an > efficient or workable solution, and not interfering with one. Or, > you see them being set aside, temporarily, if they interfere with > changes. Umm, yes and no. Parnas' Principles speak about a "software component" and the hiding of information either side of that component's interface. They do not suggest how the component should be chosen. A designer is free to divide the system up into modules as appropriate so the principles, if applied, do not restrict that choice per se. That said, a designer might use them to restrict interface sizes as with the malloc example, below. >>> [...] >> >> To me that's not information hiding but potentially excessive >> problem subdivision. > > This would go to how or when Parnas Principles are applied. > Are they applied during design, during implementation, or only > after the fact? Basically, I was seeing the X and N modules > as what I believe you're calling "excessive problem subdivision". I'm not sure why you thought that way. I don't think I even suggested it. My comment was that the Forth example you gave was excessively subdivided (as you yourself said). The X and the N modules were just algebraic references to a typical client-server-type system: one server and N clients. Such schemes are widely used. ... >> How about you? If the modularity of a system is well designed do you >> think that modular systems would be less costly to write and to maintain? > > Maybe I'm being a bit of a pessimist here ... This reminds me of both > factoring and bottom-up coding. I don't like bottom-up coding. It's > like having all the pieces to a puzzle, but the puzzle isn't solved. > I.e., this attempts to apply rules which I perceive as encapsulating or > capturing all the details without necessarily grasping the big picture, > how the parts interact or connect. I get the impression that the > principles don't allow things to interact or be modified as needed or > when needed. As I said before, I tend to believe that strict application > of Parnas Principles, or perhaps mis-application of them, will lead to > overly restrictive interfaces or overly sub-divided modules. > > So, I think you have to get to the nature of *why* the information is > being controlled. E.g., in malloc(), is it being controlled because > the user has no need for it? Or, was it hidden because they expected > an operating system to provide the functionality most of the time? > I.e., outside the scope of C's domain most of the time. If it can't > be guaranteed that the internals of malloc() are available on some > platforms, that would be a good reason to hide or restrict them. If > it can't be guaranteed the internals will be the same for all platforms, > ditto. Regardless of the reason why, making C programs ignorant of malloc's internals and having a narrow interface between app and malloc results in a lot of flexibility for both sides. Apps don't have to depend on malloc working in a specific way and malloc implementations are not required to have to deal with specific app patterns. So the design of malloc is a good example of Parnas' Principles being applied. IMO it is a good design. Of course, YMMV. James
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 08:47 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 10:56 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 19:41 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 21:08 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 21:58 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 22:55 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-06 00:01 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 00:44 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 09:45 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 07:33 -0400
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 19:14 +0100
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 20:12 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:57 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 11:55 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-07 19:04 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 10:14 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-08 07:35 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 16:22 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-09 16:45 -0400
Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-10 09:04 +0200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-10 16:30 -0400
Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-11 11:59 +0200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-11 11:06 -0400
Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-12 00:26 +0000
Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-12 09:54 +0200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-12 20:01 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-14 17:45 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 18:11 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-14 23:54 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 19:43 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 18:00 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 16:00 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 22:17 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 19:58 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-18 07:59 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 13:10 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-19 00:54 +0100
Re: A good subset of C Andy Walker <news@cuboid.co.uk> - 2014-05-15 01:31 +0100
Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-14 23:43 -0500
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 18:38 +0100
Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 11:04 +1200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-24 20:36 -0400
Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 12:53 +1200
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-24 21:34 -0400
Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 14:11 +1200
Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-25 06:47 +0000
Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-25 06:43 +0000
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 20:59 +0100
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 22:28 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:57 -0400
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 00:26 +0100
Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-06 14:21 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 15:43 +0100
Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-07 16:03 -0400
Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-07 21:31 +0100
Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-07 15:41 -0500
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:46 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-06 00:42 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-06 06:48 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 15:40 +0100
Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-08 06:50 -0400
Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 15:43 +0100
Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-08 14:41 -0400
Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-05 19:08 -0500
csiph-web