Mailing List Archive

Twigils
'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: https://github.com/Ovid/Cor/issues/29

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.
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl
Re: Twigils [ In reply to ]
On Thu, 12 Aug 2021 11:24:43 +0000 (UTC)
Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> '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:
> https://github.com/Ovid/Cor/issues/29
>
> 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.

It should also be noted that this is one of the rare few design
decisions we're having to treat entirely theoretically, based purely on
people's thoughts and opinions, and we can't back it up with observed
fact from actual practice.

This is because core perl doesn't make it possible (or at least, I
haven't found a way to make it possible) to try implementing twigils in
Object::Pad. Many of the other design shapes and choices in Corinna
have been tested out experimentally by writing real code in
Object::Pad, but this particular issue doesn't lend itself to such
experimentation.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Twigils [ In reply to ]
* Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-08-12 13:48:29 +0100]:

> On Thu, 12 Aug 2021 11:24:43 +0000 (UTC)
> Ovid via perl5-porters <perl5-porters@perl.org> wrote:
>
> > '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:
> > https://github.com/Ovid/Cor/issues/29
> >
> > 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.
>
> It should also be noted that this is one of the rare few design
> decisions we're having to treat entirely theoretically, based purely on
> people's thoughts and opinions, and we can't back it up with observed
> fact from actual practice.
>
> This is because core perl doesn't make it possible (or at least, I
> haven't found a way to make it possible) to try implementing twigils in
> Object::Pad. Many of the other design shapes and choices in Corinna
> have been tested out experimentally by writing real code in
> Object::Pad, but this particular issue doesn't lend itself to such
> experimentation.

I feel compelled to point out that this is heading in the wrong direction.

This was apparent to me when I had to consult Perl 6/Raku documentation to
see what a "twigil" was.

https://docs.raku.org/language/variables

So if there is a "debate" to be had (here), it would be regarding how
far from "trad" perl 5 you wish to deviate. My concern is that it is
heading towards Perl 6/Raku - the risk being that you'll lose the core
perl 5 audience and find yourself competing with Raku, which has a 20
yr head start.

Bear in mind, I have no issues with Raku; but I think it'd be virtual
suicide for any effort that is trying to improve the POOP experience
for Perl 5 and it's large, diverse base of users.

Thoughts?
Brett

>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Twigils [ In reply to ]
On Thu, Aug 12, 2021 at 10:51 AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> * Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-08-12 13:48:29
> +0100]:
>
> > On Thu, 12 Aug 2021 11:24:43 +0000 (UTC)
> > Ovid via perl5-porters <perl5-porters@perl.org> wrote:
> >
> > > '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:
> > > https://github.com/Ovid/Cor/issues/29
> > >
> > > 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.
> >
> > It should also be noted that this is one of the rare few design
> > decisions we're having to treat entirely theoretically, based purely on
> > people's thoughts and opinions, and we can't back it up with observed
> > fact from actual practice.
> >
> > This is because core perl doesn't make it possible (or at least, I
> > haven't found a way to make it possible) to try implementing twigils in
> > Object::Pad. Many of the other design shapes and choices in Corinna
> > have been tested out experimentally by writing real code in
> > Object::Pad, but this particular issue doesn't lend itself to such
> > experimentation.
>
> I feel compelled to point out that this is heading in the wrong direction.
>
> This was apparent to me when I had to consult Perl 6/Raku documentation to
> see what a "twigil" was.
>
> https://docs.raku.org/language/variables
>
> So if there is a "debate" to be had (here), it would be regarding how
> far from "trad" perl 5 you wish to deviate. My concern is that it is
> heading towards Perl 6/Raku - the risk being that you'll lose the core
> perl 5 audience and find yourself competing with Raku, which has a 20
> yr head start.
>
> Bear in mind, I have no issues with Raku; but I think it'd be virtual
> suicide for any effort that is trying to improve the POOP experience
> for Perl 5 and it's large, diverse base of users.
>

This seems like a pointless concern. We don't need to make decisions for
Perl based on whether they are Rakuish or not and nobody aside from us will
care. Past feature imports from Raku have varied from widely successful to
terrible failures, each needs to be judged on its effect on Perl rather
than its effect on Raku. However, this is not even a feature, it's syntax.

-Dan
Re: Twigils [ In reply to ]
* Dan Book <grinnz@gmail.com> [2021-08-12 11:06:15 -0400]:

> On Thu, Aug 12, 2021 at 10:51 AM Oodler 577 via perl5-porters <
> perl5-porters@perl.org> wrote:
>
> > * Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-08-12 13:48:29
> > +0100]:
> >
> > > On Thu, 12 Aug 2021 11:24:43 +0000 (UTC)
> > > Ovid via perl5-porters <perl5-porters@perl.org> wrote:
> > >
> > > > 'cuz we know y'all love a debate ...
> > > > We're working on the Corinnainna RFC and it won't be sent soon, but due
> > > > to Corinnainna'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:
> > > > https://github.com/Ovid/Corinna/issues/29
> > > >
> > > > 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.
> > >
> > > It should also be noted that this is one of the rare few design
> > > decisions we're having to treat entirely theoretically, based purely on
> > > people's thoughts and opinions, and we can't back it up with observed
> > > fact from actual practice.
> > >
> > > This is because core perl doesn't make it possible (or at least, I
> > > haven't found a way to make it possible) to try implementing twigils in
> > > Object::Pad. Many of the other design shapes and choices in Corinnainna
> > > have been tested out experimentally by writing real code in
> > > Object::Pad, but this particular issue doesn't lend itself to such
> > > experimentation.
> >
> > I feel compelled to point out that this is heading in the wrong direction.
> >
> > This was apparent to me when I had to consult Perl 6/Raku documentation to
> > see what a "twigil" was.
> >
> > https://docs.raku.org/language/variables
> >
> > So if there is a "debate" to be had (here), it would be regarding how
> > far from "trad" perl 5 you wish to deviate. My concern is that it is
> > heading towards Perl 6/Raku - the risk being that you'll lose the core
> > perl 5 audience and find yourself competing with Raku, which has a 20
> > yr head start.
> >
> > Bear in mind, I have no issues with Raku; but I think it'd be virtual
> > suicide for any effort that is trying to improve the POOP experience
> > for Perl 5 and it's large, diverse base of users.
> >
>
> This seems like a pointless concern. We don't need to make decisions for
> Perl based on whether they are Rakuish or not and nobody aside from us will
> care. Past feature imports from Raku have varied from widely successful to
> terrible failures, each needs to be judged on its effect on Perl rather
> than its effect on Raku. However, this is not even a feature, it's syntax.

You might think so, but back in the early 2000s when Perl 6 was getting off the
ground I could not follow once it started exploring non-Perl 5 concepts. As a
result, Perl 6 became just a curiosity to me but nothing more.

I'm only sharing a single perspective in hopes that Corinna can result in a
complemenary improvement to Perl 5 ... not yet another iceberg that is
cleaved off of this glacier that is Perl 5.

So my question more clearly is; are you trying to reimplement Perl 6 again or
are you trying to create a complementary POOP that trad Perl 5 programms will
a) consider using; but more importantly b) not refuse to maintain code that uses
it? These questions precisely define where "I'm at" in regards to all this. You
start talking stuff like "twigles" or in terms I don't recognize, then it becomes
outside of my periphery. And I'm trying to be charitable here because this seems
like a "canary in the coal mine" moment; and as I've stated before, I really want
to see this effort succeed.

Cheers,
Brett

>
> -Dan

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Twigils [ In reply to ]
On Thu, Aug 12, 2021 at 6:25 AM Ovid via perl5-porters <
perl5-porters@perl.org> wrote:

> In [Corrina], lexical variables (declared in a method or in a signature)
> can hide the instance variables.
>

This doesn't apply to Perl because instance variables already have their
own syntax. In short,

my $myflag;

and

$self->{myflag};

already don't collide.


NOT A PROBLEM, CLOSE TICKET.
Re: Twigils [ In reply to ]
On Thu, Aug 12, 2021 at 11:38 AM David Nicol <davidnicol@gmail.com> wrote:

>
>
> On Thu, Aug 12, 2021 at 6:25 AM Ovid via perl5-porters <
> perl5-porters@perl.org> wrote:
>
>> In [Corrina], lexical variables (declared in a method or in a signature)
>> can hide the instance variables.
>>
>
> This doesn't apply to Perl because instance variables already have their
> own syntax. In short,
>
> my $myflag;
>
> and
>
> $self->{myflag};
>
> already don't collide.
>
>
> NOT A PROBLEM, CLOSE TICKET.
>

This is not relevant to Corinna.

-Dan
Re: Twigils [ In reply to ]
sorry, I just became aware of Corrina today.

https://github.com/Ovid/Cor/wiki/Corinna-Overview

Could Corinna give instance variables their own syntax, differentiating
them from Perl's lexicals and package variables?

$::thing; # package var
$thing; # lexical, if defined, otherwise package
i_thing; # Corinna instance variable (or something... placeholder, not
proposal)

okay read the thing Ovid asked for comments about, I seem to have restated
the question.

On Thu, Aug 12, 2021 at 10:46 AM Dan Book <grinnz@gmail.com> wrote:

> On Thu, Aug 12, 2021 at 11:38 AM David Nicol <davidnicol@gmail.com> wrote:
>
>> On Thu, Aug 12, 2021 at 6:25 AM Ovid via perl5-porters <
>> perl5-porters@perl.org> wrote:
>>
>>> In [Corrina], lexical variables (declared in a method or in a
>>> signature) can hide the instance variables.
>>>
>>
>> This doesn't apply to Perl because instance variables already have their
>> own syntax.
>>
>> This is not relevant to Corinna.
>
--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash
Re: Twigils [ In reply to ]
> On Aug 12, 2021, at 2:21 PM, David Nicol <davidnicol@gmail.com> wrote:
>
[…]
> Could Corinna give instance variables their own syntax, differentiating them from Perl's lexicals and package variables?

At some level that’s exactly what a twigil is. You just spell it differently here than Curtis did.

-Chris

-Chris
Re: Twigils [ In reply to ]
On Thu, 12 Aug 2021 at 19:25, Ovid via perl5-porters <perl5-porters@perl.org>
wrote:

> '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:
> https://github.com/Ovid/Cor/issues/29
>
> 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
instance method
- 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
confusion

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.
Re: Twigils [ In reply to ]
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
Re: Twigils [ In reply to ]
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.
Re: Twigils [ In reply to ]
From the keyboard of Darren Duncan [13.08.21,00:58]:
[..]
> 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.

I propose $self~>x
This is close enough, but maybe not visually distinct enough. Or is it?

0--gg-

--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Twigils [ In reply to ]
On 2021-08-13 1:02 a.m., Tom Molesworth via perl5-porters wrote:
> On Fri, 13 Aug 2021 at 15:59, Darren Duncan wrote:
> 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.

I don't have a problem with the single character Huffman coding as an ADDITIONAL
option. But it needs to be in ADDITION to something like what I proposed,
because that Huffman option itself only gives access to slots for a single
object of the current class while mine works for all objects of the current
class. -- Darren Duncan
Re: Twigils [ In reply to ]
I think the idea of accessing $other's slots is debatable, and shouldn't be
used as a driving factor in this syntax discussion.
In my opinion, anyway, we shouldn't have a default way to access members of
other objects. If that sort of sharing is needed, it should be explicit
with its own interface.

On Fri, Aug 13, 2021, 12:13 Darren Duncan <darren@darrenduncan.net> wrote:

> On 2021-08-13 1:02 a.m., Tom Molesworth via perl5-porters wrote:
> > On Fri, 13 Aug 2021 at 15:59, Darren Duncan wrote:
> > 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.
>
> I don't have a problem with the single character Huffman coding as an
> ADDITIONAL
> option. But it needs to be in ADDITION to something like what I proposed,
> because that Huffman option itself only gives access to slots for a single
> object of the current class while mine works for all objects of the
> current
> class. -- Darren Duncan
>
Re: Twigils [ In reply to ]
On Friday, 13 August 2021, 10:31:49 CEST, shmnem <gm@qwurx.de> wrote:


From the keyboard of Darren Duncan [13.08.21,00:58]:
> I propose $self~>x
> This is close enough, but maybe not visually distinct enough. Or is it?

shmnem,
We had discussed possibly using ~> as the "maybe this method exists" operator, so that if we chain:
    if ( $foo~>bar~>baz ) {
        ...    }
You're saying "if all of these methods exist and the final only returns a true value, then ..."
But that absolutely would not be in the MVP.
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl
Re: Twigils [ In reply to ]
On 2021-08-13 2:18 a.m., Veesh Goldman wrote:
> I think the idea of accessing $other's slots is debatable, and shouldn't be used
> as a driving factor in this syntax discussion.
> In my opinion, anyway, we shouldn't have a default way to access members of
> other objects. If that sort of sharing is needed, it should be explicit with its
> own interface.

How is accessing the slots of $other which is of the SAME CLASS debatable? That
is a completely normal and commonly done thing and is what every single other
language in existence (that I know of) does.

If you didn't have that, how would you code the interaction of 2 objects of the
same class by way of internals that code in other classes isn't supposed to see
and hence no :reader or :writer exists?

Now I can understand Corinna having a feature different from other languages
such that it is even more restrictive, however then we need to provide a way to
grant permission to see slots of other objects of the same class.

This then comes back to the proposal I made months ago where something akin to
Raku's "trusts" feature is important, where a class can enumerate what classes
can access their otherwise private things, and in this case one would declare
that a class trusts itself.

-- Darren Duncan

> On Fri, Aug 13, 2021, 12:13 Darren Duncan wrote:
>
> On 2021-08-13 1:02 a.m., Tom Molesworth via perl5-porters wrote:
> > On Fri, 13 Aug 2021 at 15:59, Darren Duncan wrote:
> >     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.
>
> I don't have a problem with the single character Huffman coding as an
> ADDITIONAL
> option.  But it needs to be in ADDITION to something like what I proposed,
> because that Huffman option itself only gives access to slots for a single
> object of the current class while mine works for all objects of the current
> class. -- Darren Duncan
>
Re: Twigils [ In reply to ]
Having given this further thought, I concede that at the moment its hard to
think of good examples where both of the following are true at the same time for
a given class Foo:

1. A method of Foo wants to access a slot S for any other object of the Foo
class besides the $self object.

2. Slot S doesn't have any :reader or :writer or other custom public accessor
method because it isn't okay for non-Foo classes to see it.

Therefore with respect to the MVP of Corinna I withdraw my objection for the
direct access mechanism to slots of Foo being only available for the $self object.

For the MVP I consider it a reasonable compromise to have to declare a public
:reader etc method for situations where a method needs to access slots of $other
in addition to $self.

-- Darren Duncan
Re: Twigils [ In reply to ]
On Thu, Aug 12, 2021, at 7:24 AM, Ovid via perl5-porters wrote:
> 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.

I think twigils are a good idea.

--
rjbs
Re: Twigils [ In reply to ]
Please avoid twigils. They are quasi operators. As operators they ought
to be optional.

On Sun, Aug 15, 2021 at 2:09 AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Thu, Aug 12, 2021, at 7:24 AM, Ovid via perl5-porters wrote:
>
> 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.
>
>
> I think twigils are a good idea.
>
> --
> rjbs
>
Re: Twigils [ In reply to ]
On Sat, Aug 14, 2021, at 9:32 PM, Philip R Brenan wrote:
> Please avoid twigils. They are quasi operators. As operators they ought to be optional.

It is unclear what you mean by this. Twigils are not operators. (While there may have been an argument to have been made in the days of Perl v3 that sigils were operators, it ceased to hold water in Perl v5, when lexical variables eliminated the necessity of a glob in a symbol table.) Twigils are syntactic extras in the name of a variable that constrain it in some way. The dollar sign means it will be a scalar. The at sign, an array. Ruby uses sigils, of a sort, in a similar way, but largely to indicate scope. Twigils could allow multiple constraints to be applied at once.

But at any rate, do you mean that all operators should be optional? Writing a program without operators is not something to be attempted in Perl 5 for any reason other than stunt programming.

--
rjbs
Re: Twigils [ In reply to ]
Philip,
I do not know what you mean by "quasi operators" or "As operators they ought to be avoided." Perhaps if I followed P5P more closely I would get it, bu I don't. Right now, one of the biggest problems we're having with Corinna is people saying "yes" or "no" without giving concrete explanations or examples of their reasoning.
For example, here's a slot with a twigil:
has $:x;

method inc ($x) {
$:x += $x;
} 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. I see a technical argument against them (I don't know how strong it is) and two rather weak social arguments against them.
At the beginning of the discussion, I was leaning away from twigils. I kind of liked them, but I was swayed by the social arguments. Laying out the pros and cons clearly seems to show a strong benefit to using twigils.
So if you have a strong argument for or against them, if you can clearly describe it, give an example, and explain if it's a technical argument or not, I'd love to hear it (I'm quite serious about this because I'm happy to put a gun to the head of twigils, but I can't see any reason to do so at this point.)
Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl

On Sunday, 15 August 2021, 03:39:09 CEST, Philip R Brenan <philiprbrenan@gmail.com> wrote:

Please avoid twigils.  They are quasi operators.  As  operators they ought to be optional.

On Sun, Aug 15, 2021 at 2:09 AM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

On Thu, Aug 12, 2021, at 7:24 AM, Ovid via perl5-porters wrote:

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.


I think twigils are a good idea.

-- 
rjbs
Re: Twigils [ In reply to ]
Ovid

2021-8-15 15:19 Ovid via perl5-porters <perl5-porters@perl.org> wrote:

>
> For example, here's a slot with a twigil:
>
> has $:x;
>
> method inc ($x) {
> $:x += $x;
> }
>
>
>
I still don't see how it will go, however we can think about some
candidates.

Twigil:

has $:x;

method inc ($x) {
$:x += $x;
}

Variable:

has $x;

method inc($dX) {
$x = $dX;
}

Hash ref expression:

has x;

method inc($x) {
$self->{x} = $x;
}

I saw your Twitter.

Do you feel like you're being kicked out of the discussion?
Re: Twigils [ In reply to ]
On Tuesday, 17 August 2021, 06:04:48 CEST, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:


> I saw your Twitter.
>> Do you feel like you're being kicked out of the discussion?
Hi Yuki,
No, I do not feel like I'm being kicked out of the discussion. If anything, P5P has definitely been better about the discussions than conversations I've seen elsewhere. No worries :)
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl
Re: Twigils [ In reply to ]
2021-8-17 13:54 Ovid <curtis_ovid_poe@yahoo.com> wrote:

> On Tuesday, 17 August 2021, 06:04:48 CEST, Yuki Kimoto <
> kimoto.yuki@gmail.com> wrote:
>
>
> > I saw your Twitter.
> >
> > Do you feel like you're being kicked out of the discussion?
>
> Hi Yuki,
>
> No, I do not feel like I'm being kicked out of the discussion. If
> anything, P5P has definitely been better about the discussions than
> conversations I've seen elsewhere. No worries :)
>
>
That's good.

1 2  View All