Mailing List Archive

On Mon, 20 Feb 2023 at 21:55, Karen Etheridge <karen@froods.org> wrote:

> "Each has his past shut in him like the leaves of a book known to him by
> heart and his friends can only read the title."
>
> -- Virginia Woolf
>
> We are delighted to announce version 37.9,
> the tenth development release of version 37 of Perl 5.
>
> You will soon be able to download Perl 5.37.9 from your
> favorite CPAN mirror or find it at:
>
> https://metacpan.org/release/ETHER/perl-5.37.9/
>

Thank you!

Cheers,
yves

On 20 Feb 2023 21:55, Karen Etheridge wrote:
>   "Each has his past shut in him like the leaves of a book known to him by
>   heart and his friends can only read the title."
>
>     -- Virginia Woolf
>
> We are delighted to announce version 37.9,
> the tenth development release of version 37 of Perl 5.

Neat!

    #!/usr/bin/env perl
    use v5.37.9;
    use experimental qw(class);

    class Planet
    {
        field $greeting :param = 'hello';

        field $planet :param = 'world';
        method planet :lvalue { $planet }

        method greet
        {
            say ucfirst($greeting), ', ', ucfirst($planet), '!';
        }
    }

    Planet->new->greet;
    Planet->new(planet=>'Mars', greeting=>'hi')->greet;

    my $p = Planet->new(greeting=>'bye');
    $p->planet = 'venus';
    $p->greet;

(Nice that :lvalue works on method.  Hopefully that will become an
attribute on field as well.)

 – Michael

On Thu, Feb 23, 2023 at 6:01 PM Michael Schaap <perl5-porters@mscha.org>
wrote:

> Neat!
>
> #!/usr/bin/env perl
> use v5.37.9;
> use experimental qw(class);
>
> class Planet
> {
> field $greeting :param = 'hello';
>
> field $planet :param = 'world';
> method planet :lvalue { $planet }
>
> method greet
> {
> say ucfirst($greeting), ', ', ucfirst($planet), '!';
> }
> }
>
> Planet->new->greet;
> Planet->new(planet=>'Mars', greeting=>'hi')->greet;
>
> my $p = Planet->new(greeting=>'bye');
> $p->planet = 'venus';
> $p->greet;
>
> (Nice that :lvalue works on method. Hopefully that will become an
> attribute on field as well.)


Ah, crud. We should have thought to disable :lvalue. From perlsub:

Lvalue subroutines are convenient, but you have to keep in mind that, when
> used with objects, they may violate encapsulation. A normal mutator can
> check the supplied argument before setting the attribute it is protecting,
> an lvalue subroutine cannot.


Until we can figure out a way to fix this, :lvalue methods are an
astonishingly bad idea (have been long before Corinna, too).

Best,
Ovid

On Fri, 24 Feb 2023 at 17:21, Ovid <curtis.poe@gmail.com> wrote:

> Lvalue subroutines are convenient, but you have to keep in mind that, when
>> used with objects, they may violate encapsulation. A normal mutator can
>> check the supplied argument before setting the attribute it is protecting,
>> an lvalue subroutine cannot.
>
>
> Until we can figure out a way to fix this, :lvalue methods are an
> astonishingly bad idea (have been long before Corinna, too).
>

This feels too much like imposing a particular coding style on users.

As the existing documentation mentions, :lvalue is convenient - and there
have long been options such as https://metacpan.org/pod/Sentinel to provide
better control.

The caveat in the documentation seems clear enough to me, although perhaps
could be extended to include an example. Either way, no one is forced to
add :lvalue to their methods, so removing the feature would also fall into
the "bad idea" category. Why introduce an unnecessary extra difference
between methods and subs? :lvalue also allows exposing other data for
modification, not just limited to fields, so it has wider users too.

On Mon, Feb 27, 2023 at 2:27 AM Tom Molesworth <tom@deriv.com> wrote:

>
>> Until we can figure out a way to fix this, :lvalue methods are an
>> astonishingly bad idea (have been long before Corinna, too).
>>
>
> This feels too much like imposing a particular coding style on users.
>

I hear where you're coming from. I'm sorry I spoke so bluntly. I should not
have.

A few people have complained about the "imposing a particular coding style"
aspect of Corinna. The reason for this is our stated Principle of Parsimony
<https://github.com/Ovid/Cor#principle-of-parsimony>:

Many things in the proposal are deliberately restrictive, such as Corinna
> only allowing single inheritance. This is to allow Corinna to be cautious
> in not promising too much. If we later find this too restrictive, we can
> allow multiple inheritance. However, if we start with multiple inheritance
> and discover we don't need or want multiple inheritance, we would break
> existing code by taking it away.


So if we blocked :lvalue right at the beginning (I don't even know if it's
technically possible), we could potentially add it later if necessary. If
we allow it now and realize later it's a bad idea, we are stuck because
that's a breaking change. Corinna is the largest individual change to Perl
in three decades, so while I realize many people disagree with some
aspects, I hope people appreciate the caution with which we're approaching
this.

Best,
Ovid

I think you are confusing two things here.

The idea of an lvalue method is a great idea; the ability to write code
such as:

$ball->size = 10;

The way that people commonly implement them is terrible. If you just do

field $size;
method size :lvalue { $size }

then indeed that breaks encapsulation. But it's verymuch a problem of
that implementation, and not the idea itself.

Modules like Sentinel or Object::Pad::Keyword::Accessor make them a
much much safer system that doesn't violate encap. Those let the object
still run validation or post-processing trigger code, while still
giving the caller some nice simple "it looks like just setting a value"
syntax.

https://metacpan.org/pod/Sentinel

https://metacpan.org/pod/Object::Pad::Keyword::Accessor

The introduction documentation to this latter module additionally
explains further motivation for why I think it's a good idea.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On 2023-02-28 4:25 a.m., Paul "LeoNerd" Evans wrote:
> I think you are confusing two things here.
>
> The idea of an lvalue method is a great idea; the ability to write code
> such as:
>
> $ball->size = 10;
>
> The way that people commonly implement them is terrible. If you just do
<snip>

Paul makes a good point on the "idea of an lvalue method".

However, I support Ovid's point about the Principle of Parsimony in that the
safer option for now is to exclude the ability to put :lvalue on Corinna methods
for now, and optionally add that ability later.

This way we can avoid the problems from either being stuck with a poorly
designed implementation that breaks encapsulation badly, or having a breaking
change due to a need to fix that poor implementation. We can add :lvalue when
we're more certain it is done right.

I grant there is somewhat more leeway to get it wrong since "class" is
experimental, but even then, as much as possible, we should be treating all
"experimental" as if they weren't, since in practice people will use them a lot
in production, and we don't want to have to break those uses later.

-- Darren Duncan

On Tue, Feb 28, 2023 at 1:25?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> I think you are confusing two things here.
>
> The idea of an lvalue method is a great idea; the ability to write code
> such as:
>
> $ball->size = 10;
>
> The way that people commonly implement them is terrible. If you just do
>
> field $size;
> method size :lvalue { $size }
>
> then indeed that breaks encapsulation. But it's verymuch a problem of
> that implementation, and not the idea itself.
>

I confess that I am very sympathetic to this idea. To me, $ball->size = 10
is syntactic sugar for $ball->set_size(10). Admittedly, it's very pretty
syntactic sugar and I would probably use it if I knew it was safe. That
being said, is size for a field or a method? Either way, if someone wants
to change it from one to the other, the external interface should not
change in order to guarantee that we're preserving the contract the class
presents. So we need to have this behavior available for both fields and
methods without the consumer of the class being able to divine a difference
(short of metaprogramming, of course).

We also have to take care that the interface is as clean as possible and
that's going to take some design discussion. For
Object::Pad::Keyword::Accessor, we have this:

field $count = 0;

accessor count {
get { return $count }
set ($new) {
$new =~ m/^\d+$/ or croak "Invalid new value for count";
$count = $new;
}
}

That shows how difficult this can actually be. The regex probably needs an
/a at the end, or be rewritten with [0-9]. However, is a negative count
acceptable? I wouldn't think so. Do we want to allow the count to be 2e3
(2000)? Er, maybe. That will even pass the regex check, if $new is a
number, but not if it's a string. And 20e30 would never pass that regex
check, even though it might be an acceptable value. Do we want that? Also,
the set could be written as:

set ($new) {
$new =~ m/^\d+$/a or croak "Invalid new value for count";
$count = $new;
$other = rand();
}

Should we making side-effects easy be the right interface? Again, a big
design decision. We've spent years trying to design Corinna to make it easy
to follow best practices, but possible to take other approaches, when
needed. So let's say all integers are allowed and we do this to allow
lvalues:

field $count :reader :writer(:lvalue) :of(INTEGER) = 0;

That's more concise, probably handles the common cases better, it's
declarative, less likely to be incorrect, but still allows someone to
replace this with a method if they need more behavior (assuming methods
allow lvalue arguments in some fashion).

But we can't do that for now because :of(INTEGER)-style constraints would
apply to the entire language, not just Corinna, so it's probably
out-of-scope for now.

I would feel much more comfortable if Corinna was as restricted as possible
for the first release so the team can work together to figure out these
design decisions, especially given that we don't know what the original
impact of Corinna is going to be.

Best,
Ovid

On Mon, Feb 20, 2023, at 15:55, Karen Etheridge wrote:
> "Each has his past shut in him like the leaves of a book known to him by
> heart and his friends can only read the title."
>
> -- Virginia Woolf
>
> We are delighted to announce version 37.9,
> the tenth development release of version 37 of Perl 5.

Did I never reply to this?? Sorry, Karen! Thanks for the release, I used it for a whole month!

--
rjbs