Ovid via perl5-porters wrote on 15 August:
>
> Here are some of the arguments for and against them.
>
> Pros:
> • You can't accidentally shadow class/instance data. (technical)
> • Great Huffman encoding for "this is not a regular variable" (social)
> • Easy to syntax highlight (technical)
>
> Cons:
> • No direct parser support for twigils (technical)
> • Is somewhat controversial (social)
> • May contribute to "line-noise" complaints (social)
>
> I can't say that I'm "for" twigils, but so far, that's two strong technical and one strong social argument for them.
/Are/ these strong arguments, though?
The accidental shadowing argument seems to not hold much merit: We already have that same problem now in /every/ block, including experimental sub signatures, and it should be solved the same way everywhere.
As for the "not a regular variable" argument: Looking at Java, there are no sigils/twigils of course, but there is "this.", which can optionally be prepended to a name to make accessing instance data explicit. Java is kind of verbose by nature, yet few Java coders seem to use this style (except when needed to disambiguate, obviously). I personally /have/ used that coding style in Java for a few years based on the same "not a regular variable" argument and have gotten more than a few funny looks and comments about that. Eventually I gave in and have to admit: My Java code tends to be easier to read without "this.". Therefore, in my mind, the "not a regular variable" argument is also rather weak.
The synhi argument also seems pretty weak. It's /syntax/ highlighting, not semantic highlighting. All variables /should/ look the same. If you really do want to treat instance variables specially, that shouldn't be hard for today's advanced highlighters anyway by virtue of the declaration with `has`, which is easy to parse. My editor of choice doesn't have /very/ advanced highlighting, but I know this is possible with it. No twigils needed for synhi.
I got one more pro for your list, but it's also kind of weak in my opinion: Twigils could be interpolated in a string, a `slot` keyword probably couldn't. But, again, this is in no way different than any other subroutine call, which also can't be interpolated. I'd say not everything /needs/ to be interpolated.
> So if you have a strong argument for or against them, [...]
I suppose I don't? I mean, certainly not a /technical/ argument against. The thing is, I've never really used Raku, so the entire twigil concept is somewhat new to me. I'm sure Raku is great, I just never found the time to understand it. I did look into learning Raku twice, but honestly what put me off both times is all the line noise in the Raku code I looked at. I could hardly even read it.
Perl looks already noisy. Yes, it makes sense for Perl to look that way, but no need to make it worse. This is all stuff people have to invest effort to learn. A lot of the appeal of Corinna to me initially was its simplicity and elegance. Requiring twigils chips away at both of these.
IMHO, twigils should, if introduced at all (and this ought to be a big if), at least be entirely optional. That is, something like the following should be allowed:
class Point {
has $:x :param;
has $y :param;
method move ($dx, $dy) {
$x += $dx;
$:y += $dy;
}
}
--
Arne Johannessen
>
> Here are some of the arguments for and against them.
>
> Pros:
> • You can't accidentally shadow class/instance data. (technical)
> • Great Huffman encoding for "this is not a regular variable" (social)
> • Easy to syntax highlight (technical)
>
> Cons:
> • No direct parser support for twigils (technical)
> • Is somewhat controversial (social)
> • May contribute to "line-noise" complaints (social)
>
> I can't say that I'm "for" twigils, but so far, that's two strong technical and one strong social argument for them.
/Are/ these strong arguments, though?
The accidental shadowing argument seems to not hold much merit: We already have that same problem now in /every/ block, including experimental sub signatures, and it should be solved the same way everywhere.
As for the "not a regular variable" argument: Looking at Java, there are no sigils/twigils of course, but there is "this.", which can optionally be prepended to a name to make accessing instance data explicit. Java is kind of verbose by nature, yet few Java coders seem to use this style (except when needed to disambiguate, obviously). I personally /have/ used that coding style in Java for a few years based on the same "not a regular variable" argument and have gotten more than a few funny looks and comments about that. Eventually I gave in and have to admit: My Java code tends to be easier to read without "this.". Therefore, in my mind, the "not a regular variable" argument is also rather weak.
The synhi argument also seems pretty weak. It's /syntax/ highlighting, not semantic highlighting. All variables /should/ look the same. If you really do want to treat instance variables specially, that shouldn't be hard for today's advanced highlighters anyway by virtue of the declaration with `has`, which is easy to parse. My editor of choice doesn't have /very/ advanced highlighting, but I know this is possible with it. No twigils needed for synhi.
I got one more pro for your list, but it's also kind of weak in my opinion: Twigils could be interpolated in a string, a `slot` keyword probably couldn't. But, again, this is in no way different than any other subroutine call, which also can't be interpolated. I'd say not everything /needs/ to be interpolated.
> So if you have a strong argument for or against them, [...]
I suppose I don't? I mean, certainly not a /technical/ argument against. The thing is, I've never really used Raku, so the entire twigil concept is somewhat new to me. I'm sure Raku is great, I just never found the time to understand it. I did look into learning Raku twice, but honestly what put me off both times is all the line noise in the Raku code I looked at. I could hardly even read it.
Perl looks already noisy. Yes, it makes sense for Perl to look that way, but no need to make it worse. This is all stuff people have to invest effort to learn. A lot of the appeal of Corinna to me initially was its simplicity and elegance. Requiring twigils chips away at both of these.
IMHO, twigils should, if introduced at all (and this ought to be a big if), at least be entirely optional. That is, something like the following should be allowed:
class Point {
has $:x :param;
has $y :param;
method move ($dx, $dy) {
$x += $dx;
$:y += $dy;
}
}
--
Arne Johannessen