Larry Wall skribis 2005-03-07 8:40 (-0800):
> 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 { ... }
That someone took the time to bring this up pleases me. I'm very strict
when it comes to indenting and what I find most readable and thus
prefer. Of course, everyone should have their own style and there's no
shame in having something that some consider ugly. Still, for my own
code, I wish to keep things the way they are.
I indent in two situations. The first is continuation of a statement,
when things don't fit in 80 characters. I try to do this after an infix
operator, or before it if the infix operator is or/and/xor/||/$$/->. The
only thing changing there is the addition of ^^, // and err. And of
course that -> is now spelled ..
The second place where I allow myself to indent is within nested
brackets, or sometimes some other circumfix delimiter. If an { belongs
to a certain control statement, it should not have its own line. If any
newline is in the delimiters, even the first and last elements in them
should be on their own lines.
Indentation is always 4 columns. Never 8, never 2. The only exception is
vertical alignment. Outdents exist only to naturally end indentation.
Subs are a problem in Perl 6, because their declaration can be very long
and easily span multiple lines.
With my current "rules", I'd end up with
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) returns Footype is good is bad is ugly {
...
}
The { is not really on the same line as "method", but at least it's not
on its own.
But it is indeed hard to parse a list of things that have no well
visible separator. I could break my one-space-max rule:
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) returns Footype is good is bad is ugly {
...
}
But that feels like there really are commas, but they were made
invisible. I could also break my continued-lines-are-indented rule:
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
)
returns Footype
is good
is bad
is ugly {
...
}
But then, the other way around is prettier:
method foo
returns Footype
is good
is bad
is ugly (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) {
...
}
Not that I like ") {", but I'm used to seeing it from Perl 5's if. This
makes "method foo" look much less important than it is. But with
indentation, the block is no longer clearly visible:
method foo
returns Footype
is good
is bad
is ugly (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) {
...
}
Or { needs to go on its own line, which really disturbs me if the { is
not the beginning of a term. And this style is wrong because either ()
or {} need to not line up.
The thing missing is indeed the comma. Looking for other places where
comma is "missing", I thought of qw, or its new <> variant. Isn't the
following a neat solution for the problem we're faced with?
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) returns Footype, is <good bad ugly> {
...
}
Okay, I cheated by still adding a comma. How about allowing this then:
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) :returns<Footype> :is<good bad ugly> {
...
}
I'm not sure what to think of my own suggestion. I find this neat and
ugly at the same time. Ugly, because now something that used to be
barewordish/keywordish now feels like strings, beatiful because it solves
a problem, neat because it's syntax that exists elsewhere too.
I think allowing comma or finding another character that can replace it
is the best option, but I think we're low on ASCII characters. Backticks
can be beatiful, but not for this :)
Hm, infix +? If I understand things correctly, it's invalid in the
current design anyway. It communicates that things all belong together,
but it looks really weird:
method foo + returns Footype + is good + is bad + is ugly
And it really screams for allowing different order:
is good + returns Footype + method foo + is bad + is ugly
So that is probably not a good idea. Infix & has the same advantage and
disadvantage. The obvious characters, comma, and semicolon are out of
the question because of my/our/has. But could ~ work? I know they're not
strings, but string concatenation doesn't make sense in this syntactical
context anyway.
method foo ~ returns Footype ~ is good ~ is bad ~ is ugly (
...
) {
...
}
This can even serve as a visual indentation without really indenting if
you put them all on their own lines:
method foo
~ returns Footype
~ is good
~ is bad
~ is ugly (
...
) {
...
}
And it doesn't look bad after the signature either:
method foo (
...
) returns Footype ~ is good ~ is bad ~ is ugly {
...
}
But this works only for verticality if they're allowed between signature
and traits too:
method foo (
...
)
~ returns Footype
~ is good
~ is bad
~ is ugly {
...
}
I like the previous better, though:
method foo
~ returns Footype
~ is good
~ is bad
~ is ugly (
...
) {
...
}
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
