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

Re: Twigils

Thread Previous | Thread Next
Darren Duncan
August 13, 2021 07:58
Re: Twigils
Message ID:
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:

   (any appropriate value expression)->{z}

The Corinna way:

   (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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About