Front page | perl.perl5.porters |
Postings from August 2021
Re: Twigils
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
August 13, 2021 07:58
Subject:
Re: Twigils
Message ID:
f096a227-c324-2f99-58f1-15c80114584d@darrenduncan.net
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.
The blessed hash way:
$self->{x}
$other->{y}
(any appropriate value expression)->{z}
The Corinna way:
$self->!x
$other->!y
(any appropriate value expression)->!z
Or something like that.
When I say that slots should have their own namespace, the above is what I
really mean, each object such as $self or $other IS the namespace for the slots,
and all other kinds of Perl variables continue to scope/behave as they did before.
We really don't need twigils, but we do need the "->" alternative to mean its a
slot direct access, whereas plain -> would apply to a defined :reader etc if and
only if they exist.
-- Darren Duncan
Thread Previous
|
Thread Next