-
Notifications
You must be signed in to change notification settings - Fork 591
Rearranging and revising the "open" section of perlfunc.pod for clarity #17717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rily (but not limited to) splitting it into several nested sub-sections, with headers.
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Grinnz
reviewed
Apr 14, 2020
Nice improvement overall. 👍 |
FYI the test failures are from pod checker:
Basically a bunch of your lines are too long because they are in nested =over, and the other ones are probably lines with trailing whitespace. |
… new first heading.
…y're built-ins filehandles.
Grinnz
reviewed
Apr 17, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
open
section of theperlfunc
manual page comprises a single, very long section of text, interspersed with example-code blocks, covering many features of this complex and core Perl function. While every individual sentence or example within this text is factually accurate, the whole page makes for quite a daunting read. It runs for the length-equivalent of six printed pages with no sub-headings, frequently changing its focus on different aspects ofopen
while not necessarily clarifying which construe common cases or best practices.This pull request proposes revisions to address these issues. It aims to make this documentation section more approachable to Perl newcomers, without losing its value as a thorough reference.
Most significantly, this work rearranges the content into several nested sub-sections. Since
perlfunc
lists all its functions as=item
entries within one single and enormously long=over/=back
pair, I have implemented these sub-sections as=over/=back
sub-lists, with=item
s serving as headers. (A handful of otherperlfunc
sections, such aseval
, do something like this already.)I ordered these sections, and rearranged the existing documentation under them, so as to put
open
best practices and most-common use-cases first. After it explains usingopen
with normal files, the text describes somewhat less-common use-cases of opening filehandles into commands and scalar references, before getting into rarer uses like duping. It ends with "legacy syntax" of callingopen
with less than three arguments, and then a miscellany of other considerations and cross-references.While most of the text is unchanged from that currently found in
blead
, I did add or update some text for the sake of improved flow within this new arrangement. I also took the liberty to rewrite the introductory paragraphs, prior to the first sub-header, making an effort to define and demystify "filehandle" as soon as possible.An aside, for transparency's sake: I submit this work as part of a TPF-funded project, whose original proposal you can read online.