On Mon, Mar 07, 2005 at 12:55:49PM +0200, wolverian wrote:
: Hello all,
:
: while writing some experimental code with Pugs, I realised that it is a
: bit hard for me to parse the following type of declaration:
:
: sub greeting (Str $person) returns Str is export {
: "Hello, $person"
: }
:
: Specifically, the 'is export' trait is too buried.
Here are some alternatives you don't seem to have considered:
sub greeting (Str $person) is export returns Str {
"Hello, $person";
}
sub greeting (Str $person) is export
returns Str {
"Hello, $person";
}
sub greeting (Str $person)
is export
returns Str {
"Hello, $person";
}
sub greeting (Str $person)
returns Str
is export {
"Hello, $person";
}
my Str sub greeting (Str $person) is export {
"Hello, $person";
}
my Str
sub greeting (Str $person) is export {
"Hello, $person";
}
: Reformatting it like this helps:
:
: sub greeting (Str $person)
: returns Str is export {
: "Hello, $person"
: }
:
: But I really do not like the vertical alignment of the traits and the
: body of the sub. So we're back to the first situation. We could also put
: the 'returns' on the first line, after the signature (and strictly
: speaking it at least can be a part of the signature), and the traits on
: successive lines after that, but the alignment problems kicks in again.
:
: There are other ways to format the declaration, like indenting the
: traits line:
:
: sub greeting (Str $person) returns Str
: is export {
: "Hello, $person"
: }
:
: This looks distinctly odd to me, although I think it works better than
: the aligned version. Moving the traits line to column 0 is even weirder.
:
: I think it is clear that I do not want to put the { on its own line. :)
That's how I started out in C, and then eventually mutated to a form
in which I put the { on its own line only if I had multiple lines in
the signature. In that case I decided the consistency was overrated.
I basically do the same with any bracketing construct now--if the front
stuff rates more than one line, then I pull the brack out front on its
own line, and not otherwise. It seems the least insane approach to me,
but I realize the inconsistency will bug some people more than others.
Anyway, this policy works for me, and for more than just sigs--it makes
it possible to split up the parameters when they are long and
complex, so I can happily write anything from
sub Foo foo (Bar $bar) is export {
...
}
to
method foo ( $self:
$odd returns Int where { $_ % 1 },
$even return Int where { not $_ % 1 },
Block ?&permutator,
[EMAIL PROTECTED]
)
returns Footype
is good
is bad
is ugly
{
...
}
or maybe
method foo ( $self:
$odd returns Int where { $_ % 1 },
$even return Int where { not $_ % 1 },
Block ?&permutator,
[EMAIL PROTECTED] )
returns Footype
is good
is bad
is ugly
{
...
}
Well, that's not exactly pretty, but I figure that if you've blown
that many lines on the signature, another line for the opening curly
isn't that much, and makes it visually easy to find where the code
actually starts. Anyway, I think it's more important to have a style
that can mutute from horizontal to vertical form than it is to have
a consistent style.
: The problem can be alleviated a bit by giving each trait a more
: separable visual identity:
:
: sub greeting (Str $person) returns Str, is export {
: "Hello, $person"
: }
:
: The above works better for me than either of the previous examples. So
: my question is: can this be legal Perl 6 code (and will it DWIM)? There
: are ways to format this I didn't think of, I'm sure, so I'd like to know
: too what the recommended style is. (perl6doc perlstyle...)
:
: This same problem (well, it is a problem to me) applies to other places
: where traits are used as well, but I'm specifically asking in the
: context of named subroutine declarations, since parsing the comma seems
: at least possible there. The visual distinction in a regular 'my'
: declaration brought by the comma might also look too much like a list.
: (It probably is a list.)
Yes, that's the basic problem with comma, and the declaration of traits
on "my" and "sub" is one thing I *would* like to keep consistent. I'm
not consistent about consistency, you see, except when I am...
And I try to believe six foolish consistencies before breakfast each day. :-)
Larry
