Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #2266
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: A good subset of C |
| Date | 2014-05-18 13:10 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.xf2fbp056zenlw@localhost> (permalink) |
| References | (15 earlier) <ll84id$b6a$1@dont-email.me> <op.xf0siais6zenlw@localhost> <ll8jnp$qea$1@dont-email.me> <op.xf03jult6zenlw@localhost> <ll9lp4$9gl$1@dont-email.me> |
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... >> Which one did we choose? >> >> The answer to one of your questions is: "No idea ..." >> >> The answer to the other is #3. > > :-( I've lost track of which question needs to be put with which answer. > Lol. I only posed one question. The other should've been one of confusion: JH Q: "WTF does any of this have to do with information hiding? ..." RP A: "No idea..." :-) >> 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. >> [...] > > 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.e., I was viewing them from the perspective that something like a sort routine was distributed across multiple modules, or maybe something high throughput, say video, had a very restrictive interface. > Isn't information hiding more about keeping *data* separate? I wouldn't know. I'm only going on what you introduced from the link and within this conversation. E.g., you introduced the "interface" and "module". > Parnas' Principles and others related to software system construction > are about helping rather than hindering. But, there are clearly too many unknowns. (Or, at least, I don't know them.) When are they applied? Who is best to apply them? Are they applied throughout the design process or only at the end? Can they be set aside to make changes? etc. > Changing the internals of a module has a cost and some benefits. Yes. > Changing an interface has a cost and some benefits. Yes. > If the benefits of changing an interface outweigh the cost > then it's worth doing. I'm presuming that if the maintenance programmer or original author(s) decide to change such things, they should know the benefits and have decided those benefits are worth the change, or they wouldn't bother. > 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. A function like strtok() is going to be implemented in C everywhere. So, there is no point to restrict access to it's internals, unless it's some sort of safety issue or issue with global access, neither of which I recognize currently. Personally, I'd think that these would be better principles: 1) do what needs to be done, but no more 2) do it as efficiently as you can Rod Pemberton
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