9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: lucio@proxima.alt.za
To: 9fans@9fans.net
Subject: Re: [9fans] Ports tree for Plan 9
Date: Sat, 30 May 2015 08:36:52 +0200	[thread overview]
Message-ID: <63eb016ed1ac0ade586c2544d55e774a@proxima.alt.za> (raw)
In-Reply-To: <CAHJeKDVQvtQiZG0ZOEACD-1un7E2PFn4P2ZP7tWcAXVA9ZGASA@mail.gmail.com>

>> It is the Plan 9 Way (TM) to avoid > nested inclusion of header files,
>
> $ arch/dat.h includes port/portdat.h in kernel. Exempted too?

That's out of necessity, the alternative(s) would be considerably less
practical.  If memory serves, port/portdat.h is not strictly a header
file in the connventional "C" sense.  If memory serves, it would also
be possible to arrange the 9 kernel sources in a more elegant manner,
but the cost to benefit ratio would be too low to bother.

Note that no one has ever prohibited nesting includes where it could
have been possible to do it in the compiler and pre=processor.  It is
not a crime, it is a bad practice.  I'm of the opinion that it is as
avoidable as the GOTO command in programming languages (I don't use
GOTOs and don't really cope well reading code that does), but there is
enough code out there to suggest my opinion needs a formal proof.

So, yes, I think there are exceptions and the one you quote is not the
only one, mostly for historical reasons; it is also my belief that
such exceptions could be eliminated, but with the advancing of time,
it becomes less and less practical to do so.  Further, I mentioned
exemption for APE because it is an uncomfortable reality we don't need
to encourage: like the kernel stuff that dates back to the 1980s, once
adopted, it becomes very hard to eliminate.

Lucio.




  reply	other threads:[~2015-05-30  6:36 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12  5:45 mveety
2015-05-12 10:26 ` Jens Staal
2015-05-14  7:05 ` Jens Staal
2015-05-14  8:46   ` cinap_lenrek
2015-05-14 10:42     ` Jens Staal
2015-05-14 10:47       ` cinap_lenrek
2015-05-14 10:52       ` cinap_lenrek
2015-05-14 11:10         ` Jens Staal
2015-05-14 11:49           ` Jens Staal
2015-05-14 11:59             ` cinap_lenrek
2015-05-14 12:13             ` cinap_lenrek
2015-05-14 12:36             ` cinap_lenrek
2015-05-14 11:50           ` cinap_lenrek
2015-05-14 13:32             ` Steffen Nurpmeso
2015-05-14 14:37               ` cinap_lenrek
2015-05-15  4:43                 ` Jens Staal
2015-05-15  5:21                   ` cinap_lenrek
2015-05-15  5:53                   ` cinap_lenrek
2015-05-15  7:08                     ` Jens Staal
2015-05-18 15:57                     ` Jens Staal
2015-05-27 19:49                       ` cinap_lenrek
2015-05-29 21:01                         ` erik quanstrom
2015-05-29 21:12                           ` Kurt H Maier
2015-05-30  5:11                             ` lucio
2015-05-30  5:57                               ` Álvaro Jurado
2015-05-30  6:36                                 ` lucio [this message]
2015-05-30  6:13                               ` Kurt H Maier
2015-05-30  6:39                                 ` lucio
2015-05-30  6:59                                   ` Kurt H Maier
2015-05-30  7:04                                     ` Kurt H Maier
2015-05-30  8:36                                     ` lucio
2015-05-30 15:54                                     ` erik quanstrom
2015-05-30 16:17                                       ` Kurt H Maier
2015-05-30 16:27                                         ` Jeff Sickel
2015-05-30 20:30                                           ` Stanley Lieber
2015-05-30 20:32                                       ` Stanley Lieber
2015-05-31  0:16                                         ` erik quanstrom
2015-05-31  3:04                                     ` arnold
2015-05-31  4:40                                       ` Kurt H Maier
2015-05-31  4:55                                         ` erik quanstrom
2015-05-31  5:01                                           ` erik quanstrom
2015-05-31  5:17                                           ` Kurt H Maier
2015-05-31 14:00                                         ` arnold
2015-05-31 14:12                                           ` erik quanstrom
2015-05-31  5:08                                       ` lucio
2015-05-31 14:03                                         ` arnold
2015-05-30  7:21                                   ` Jens Staal
2015-05-30  8:21                                     ` Charles Forsyth
2015-05-30  8:35                                       ` Jens Staal
2015-05-30  8:41                                         ` lucio
2015-05-30 15:57                                 ` erik quanstrom
2015-05-29 21:25                           ` cinap_lenrek
2015-05-30  3:02                             ` erik quanstrom
  -- strict thread matches above, loose matches on Subject: below --
2015-05-31  0:41 sl
2015-05-15  4:49 mveety
2015-05-12  2:02 mveety
2015-05-12  4:16 ` Jens Staal
2015-05-12  6:19 ` Ori Bernstein
2015-05-14  1:03 ` Adrian Regenfuss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63eb016ed1ac0ade586c2544d55e774a@proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).