>So this would break any code which interacts with pod: Pod::Usage, perlman,
>perlhelp, etc.
NB: perlhelp == perlman with a particular metapage named perlhelp,
which knows to search the pod library linewise.
>Which I suppose just adds weight to the don't go there,
>highly discouraged ultimatum.
>I don't think that the documentation should be removed from the core
>distribution, BUT I do think that there should be an "easter egg" that
>allows people to build a Perl distribution without documentation or
>whatever else they choose. There have been times that I've
>wanted/needed to build a
>>>>>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>TC> I would be opposed to any mechanism that could allow people
>TC> to have their code without its attendant documentation.
>Why?
>What if I have one or two development boxes, an
>> (SE), AFAIK, and therefore the man pages should be an option that could be
>> deleted to save space.
>This is already an option, and has been for years. I don't imagine that
>would change in perl6.
I should much prefer to see random modules deleted instead.
--tom
I would be opposed to any mechanism that could allow people
to have their code without its attendant documentation.
--tom
>> Alongside giving consistent APIs I think perl6 should also give consistent
>> documentation format.
>Are there any proposals to add per-argument markup to POD so that these
>could be generated automatically? (Even in the 'locally preferred style'
>if necessary).
If people are already not foll
>I think no matter what is decided, consistency-wise, someone is going to be
>unhappy with it. If we use DumpCore() the C programmers won't like us,
>dump_core() and the C++ and Java programmers will throw fits. I think the
>best thing we can do is decide on what -Perl- programmers want.
>Unfor
>Michael Fowler sent the following bits through the ether:
>> Personally, I think FindBin is a bit of a sore thumb. Its name, the
>> capitalization of its variable names
>I suppose we could try and define some Perl Naming Conventions - ie
>instead of DumpCore() we should have dump_core().
Agr
>Is it worth an RFC proposing that the POSIX module is split into managable
>chunks or is this a non-issue given that it can be done for perl5 now if
>someone had the free time?
I'm unclear whether that's actually a great thing, since the motivation
is due to an internals performance screw-up.
B
>I haven't seen any messages from this list and am wondering if
>I have some sort of configuration problem or if, indeed, there
>has been no traffic. (There doesn't seem to be an archive on
>http://tmtowtdi.perl.org/lists.shtml even though there is a link)
All are sleeping?
--tom
10 matches
Mail list logo
