develooper Front page | perl.perl5.porters | Postings from August 2021

Re: Twigils

Thread Previous | Thread Next
From:
Tom Molesworth via perl5-porters
Date:
August 13, 2021 08:02
Subject:
Re: Twigils
Message ID:
CAGXhHdnY8w9-E+-7hqyLYmG-R3R_yA1RL+bmsbW215-xA8A0_Q@mail.gmail.com
On Fri, 13 Aug 2021 at 15:59, Darren Duncan <darren@darrenduncan.net> wrote:

> On 2021-08-13 12:16 a.m., Tom Molesworth via perl5-porters wrote:
> > Personally I'd suggest that enforcing twigils would be a bad idea, for
> reasons
> > including the following:
> >
> > - 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
> >
> > 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.
>
> I believe the best way to design this is to do something that directly
> mirrors
> the current blessed hashref approach, which is that you ALWAYS reference a
> slot
> in terms of a subscript of an object of the type.
>

Strong disagreement from me on this - after using Object::Pad for a while,
it's painful to go back to the old approaches.

Slot access is a common operation, so I find the single-character Huffman
encoding we have now to be an excellent fit.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About