Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2229

Re: A good subset of C

From "Rod Pemberton" <dont_use_email@xnothavet.cqm>
Newsgroups comp.lang.misc
Subject Re: A good subset of C
Date 2014-05-09 16:45 -0400
Organization Aioe.org NNTP Server
Message-ID <op.xfl1afv66zenlw@localhost> (permalink)
References (4 earlier) <lkd3fo$2mv$1@dont-email.me> <op.xfiic4pj6zenlw@localhost> <lkfht2$k2p$1@dont-email.me> <op.xfjg4u1y6zenlw@localhost> <lkg7fg$aek$1@dont-email.me>

Show all headers | View raw

On Thu, 08 May 2014 11:22:31 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xfjg4u1y6zenlw@localhost...

>> I.e., I keep getting the impression you're attempting to interface with
>> a "black box".
>
> OK. Am guessing as to why you might get that impression but possibly it
> is because I try to modularise quite a lot.

Ok.  Yeah, that could be it.

It just seems to me sometimes that it's like you're creating something
which has no information about what it is connecting with, none, zero.

;-)

> Have you come across these principles?
>
>   [Parnas "rules"]
>

I'm going to say: "No."

Of course, one could say the phrase "should provide no other information"
of each clause is rather vague, unclear, and/or arbitrary, etc.

What exactly is the meaning of "no other information" in that context?
Does the "no other information" refer to,

A) for the 1st clause:
  1) exclusively information completely unrelated to the "services
provided" or external to it?
  2) #1 and the information for services not necessarily needed for
"effective use" but still provided for use?
  3) any information related to the "services provided" which are
internal to those services which may be exposed to the user?

etc.

B) for the 2nd clause:
  1) information completely unrelated to the "responsibilities
assigned"?
  2) information for responsibilities not assigned but may
eventually be assigned?

etc.

I would have argue that limiting some information, which Parnas
thinks clearly thinks is irrelevant or extraneous, would cause
design or implementation problems in the future.  The phrases
"too limiting" and "too unknown" comes to mind.

E.g., I would expect to have *all* information needed to use
the services even if some of that information is *not* needed
for "effective use".  It may still be required for uses which
are arbitrarily deemed ineffective use by others.

E.g., if your manager says that there is the possibility the
code will be extended in a certain way in the future, you're
going to allow for that in your current design even though
it's *not* an assigned responsibility.  If you don't, you
could have serious problems fixing things in the future.

Rules always have a reason for their existence, but the rules
never tell you _why_ the rule was created in the first place.
The rules never tell you their purpose.  So, you always have
determine why the rule exists, what are the original constraints
under which the rule was created, and then you have to ask if
the rule is still valid or ever made any sense at all.

So, you may want ask yourself what is the real purpose behind
the Parnas rules:

1) is it to prevent code bloat?
2) is it to prevent feature creep?
3) is it to prevent miscommunication?
4) is it to prevent coding mistakes?
5) is it to prevent conflicts between user and developer?
6) is it to control proprietary information?
7) is it to keep a project on target, on budget?
etc.


A "slide" or two back:

"The user of a software component need only know what it does,
not how it does it."

I would agree and disagree with that.  Who is the user?  It doesn't
define who the "user" is.  Without defining that, the statement may
be invalid.  I.e., does user mean *all* users with *no* exceptions?

If the "user" is an end-user of an application, then they can be kept
in the dark.  They only need to understand the application's interface,
and don't need to understand anything to do with the modules involved.
Information hiding works just fine for them.

If the "user" is another computer programmer, then they *absolutely*
need to know what the "software component" does to make a decision as
to whether the component is capable of "effective use" or not.

A programmer needs to understand the modules interface and how the
module works.  If the programmer goes ahead and uses the "black box"
without understanding what it does because he/she has no access to it,
that could create some future complications.  It may be doing too much,
not enough, be too slow, or be doing something it's not supposed to do.

It seems this is about object-oriented languages, and it mentions
"information hiding".  As a programmer, information hiding is a
*bad* thing.  That's when an internal function has been hidden
or not exposed, or when access to it has been denied.  It's always
in those situations that you find you need access to that component.
You know what you need is in there, but you can't use it, e.g.,
intermediate operation in a C library function, or a sub-function
used by the OS, etc.

IMO, one of the reasons that C is viewed as a "rich" language for
programming is because almost everything the language does is available
to the programmer for their use, i.e., very little is hidden or restricted.

> The approach is a form of data hiding and an excellent approach, IMO.
>
> The effort to reduce 'public' information may be why to you I seem to be
> interfacing with a black box. As part of the topic we are discussing,
> though, I would put public interface information into a C header file.

...


Rod Pemberton

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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