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
Usage does not print required type for positional params in MAIN #4265
Comments
From @bbkrNamed params print required types: 17:33 bbkr: r: sub MAIN (Int :$x!) {...} However positional types does not: 17:33 bbkr: r: sub MAIN (Int $x!) {...} I think this is bug because type is more important than irrelevant variable name. |
From @pmichaudOn Tue May 26 08:38:30 2015, bbkr@post.pl wrote:
In this case, the variable name is "irrelevant" primarily because the programmer chose an irrelevant name. A clearer case for the current behavior comes from sub MAIN (Int $count!) { ... } which produces a more useful "Usage: /tmp/tmpfile <count>" message. Or consider a grep-like replacement: sub MAIN ($pattern!, @*files) { ... } that produces "Usage: /tmp/tmpfile <pattern> [<files> ...]". In the original report, an argument can be made that the programmer ought to have made the program more useful by writing sub MAIN (Int $integer) { ... } which outputs "Usage: /tmp/SJk_VxNAxM <integer>". I'm inclined to reject this ticket, but will leave it open for further discussion. Pm |
The RT System itself - Status changed from 'new' to 'open' |
From @bbkr
What if there are two integer params? MAIN (Int $integer1, Int $integer2) looks bad and subroutine body may be hard to understand. Despite that I found another inconsistency in positional params - anonymous one still display types: $ perl6 -e 'sub MAIN (Int, Str) { ... }' Maybe more consistent way of displaying types would be: |
From @bbkrBTW: whatever decision for this ticket will be, also there is inconsistency between usage text and how Perl 6 display types: $ perl6 -e 'Int.WHAT.say' So it should be displayed as --age=(Int) instead of --age=<Int>. |
From @bbkr
What if there are two integer params? MAIN (Int $integer1, Int $integer2) looks bad and subroutine body may be hard to understand. Despite that I found another inconsistency in positional params - anonymous one still display types: $ perl6 -e 'sub MAIN (Int, Str) { ... }' Maybe more consistent way of displaying types would be "--age=<Int> --name=<Str>" for named and "<Int>age <Str>name" for named positionals and "<Int> <Str>" for anonymous positionals?
|
From @sjnI think this bug can be closed. Here's my reasoning. For me, a major point with the auto-generated usage text is that it helps the developer of the program see the importance of picking good variable names. If a dev chooses to name them $integer1 and $integer2 (which are obviously horrible variable names because they tell nothing about what they will be used for), then the generated usage text *should* looks stupid. Garbage in, garbage out. In the same way, if the name of the variable doesn't give an indication of the type (e.g. $age is a number), then the error is still with the developer and not the language. This is a non-issue, and the ticket should be closed. :) - Salve (who is looking through all tickets related to MAIN) Wed, 27 May 2015 06:11:13 -0700 skrev bbkr@post.pl:
|
From @zoffixznetOn Sat, 30 Sep 2017 12:45:09 -0700, sjn-perlbug@pvv.org wrote:
Agreed. Rejecting. I see little reason to muddy up the Usage even more with type information, The type info is helpful with named args, because without types present,
Don't see much consistency relevance between USAGE and the behaviour of the
Seems reasonable to me. Lacking a variable name, there's little else Cheers, |
@zoffixznet - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#125251 (status was 'rejected')
Searchable as RT125251$
The text was updated successfully, but these errors were encountered: