Front page | perl.perl5.porters |
Postings from August 2021
From: Tom Molesworth via perl5-porters
August 13, 2021 07:16
Message ID: CAGXhHdm6pMK7KygUVK4qAdc16HnhmudDuFfv_vD1QLEbmsPHFA@mail.gmail.com
On Thu, 12 Aug 2021 at 19:25, Ovid via perl5-porters <firstname.lastname@example.org>
> 'cuz we know y'all love a debate ...
> We're working on the Corinna RFC and it won't be sent soon, but due to
> Corinna's design, we have a subtle issue that isn't shared by most other OO
> languages. In short, lexical variables (declared in a method or in a
> signature) can hide the instance variables. Twigils is one way of solving
> that issue.
> I've described it in more detail here:
> We have not made a decision, but we'd like to know if P5P would consider
> this acceptable or not. We know that for many people, twigils can be a
> hot-button issue.
Personally I'd suggest that enforcing twigils would be a bad idea, for
reasons including the following:
- shadowing is sometimes desirable, and already applies to any variable
(`our` / `my`)
- it's easily supported with current syntax if you use `$_slot`, as already
found in CPAN examples
- it causes extra work when refactoring between proof-of-concept and
- if you have a lexical variable with the same name as a slot, then
conceptually that's a naming problem, not a syntax one - putting them in
different namespaces doesn't fix the original problem at all
- it'll be introducing a new concept and syntax with potential for more
Being able to move code around and use slots, parameters or something
pulled in from an outer scope _without any change at all_ has been very
useful when working with Object::Pad-based projects. The only argument I'd
have in favour of twigils would be "it allows a $self slot", and that's far
outweighed by the points against it.
I would also recommend that anyone proposing twigils should at least spend
some time working with Object::Pad code using the `$_emulated_twigil`
syntax, trying a few refactoring and code evolution tasks, rather than
taking a purely academic approach. The separate namespace aspect appealed
to me at first, for example - especially with a C++ background - but it
didn't take long to change my mind after moving a few blocks of code around.