I'm happy to see new documentation, including the .dev files, appearing
in parrot. However, I do have a small concern that we not set ourselves
in a position of maintaining multiple copies of the same information.
To be specific, I looked at byteorder.dev and noted a listing of all the
-
From: Andy Dougherty [EMAIL PROTECTED]
To: Perl6 Internals [EMAIL PROTECTED]
Sent: Wednesday, July 17, 2002 1:35 PM
Subject: [PATCH] .dev files.
I'm happy to see new documentation, including the .dev files, appearing
in parrot. However, I do have a small concern that we not set ourselves
Tanton Gibbs wrote:
. . . That saves a person digging through
the .c file to find what they are looking for.
Perhaps we could automatically update the .dev
file with the POD found in the .c file?
As someone else has already said, a better place
for the .dev information might be inside the
viewing of only the POD information.
Tanton
- Original Message -
From: John Porter [EMAIL PROTECTED]
To: Perl6 Internals [EMAIL PROTECTED]
Sent: Wednesday, July 17, 2002 2:39 PM
Subject: Re: [PATCH] .dev files.
Tanton Gibbs wrote:
. . . That saves a person digging through
the .c
John Porter:
# Tanton Gibbs wrote:
# . . . That saves a person digging through
# the .c file to find what they are looking for.
# Perhaps we could automatically update the .dev
# file with the POD found in the .c file?
#
# As someone else has already said, a better place
# for the .dev
Brent Dax wrote:
Do you really want to see a ten-page discussion of hashing
algorithms and why the current one was chosen in the middle
of classes/perlhash.pmc?
I guess that wouldn't bother me as much as it might bother
some other people.
*That's* the sort of thing the .dev files are for,
On Wed, 17 Jul 2002, John Porter wrote:
As someone else has already said, a better place
for the .dev information might be inside the .c
file itself.
I for one find the separation unnatural,
uncustomary, and de-sync-prone.
Frankly I just don't see what it buys us.
Obviously, in principle,
Andy Dougherty wrote:
I think the purpose of the .dev files, as laid out in
docs/pdds/pdd07_codinstd.pod, is a reasonable one.
Here's an edited excerpt: . . .
(Thanks, Andy.)
Well, given that definition of the purpose, I must
persist in my opinion that the proper place for that
kind of
On Wed, Jul 17, 2002 at 03:56:39PM -0400, Andy Dougherty wrote:
In practice, what we need is a supporting culture and infrastructure to
make it most likely that useful documentation will get written and be
in a place you can find it.
Obviously, in practice, judgment will be needed for any
very recently I wrote:
... fine. Whatever.
People, if I'm coming across with a nasty or petulant tone,
I sincerely apologize. It's really not what I was going for.
jdp
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
On Wed, Jul 17, 2002 at 01:42:17PM -0700, John Porter wrote:
Andy Dougherty wrote:
I think the purpose of the .dev files, as laid out in
docs/pdds/pdd07_codinstd.pod, is a reasonable one.
Here's an edited excerpt: . . .
(Thanks, Andy.)
Well, given that definition of the purpose, I
On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote:
One of the reasons I used numerical accuracy as an example was because
in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhere
in the middle of the 10,000 line sv.c, and thus probably hasn't been seen
by most
On Wed, Jul 17, 2002 at 11:13:58PM +0100, Nicholas Clark wrote:
On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote:
One of the reasons I used numerical accuracy as an example was because
in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhere
in the middle of the
For what it's worth, I agree. I think that when your documentation is
tied to the structure of your source files, it only makes sense to put it
IN the source files.
I don't think you can do literate programming half-way. While I don't
think literate programming is the right thing to do to
14 matches
Mail list logo
