Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?

by 1nickt (Canon)
on Oct 15, 2019 at 01:25 UTC ( [id://11107461]=note: print w/replies, xml ) Need Help??


in reply to Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
in thread If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?

I don't get why you dislike Moo, but anyway have you tried Method::Signatures for signatures including named params, and constraints? It's quite powerful.


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^3: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by Corion (Patriarch) on Oct 15, 2019 at 15:42 UTC

    I don't dislike Moo in the general sense, but more my (and my perceived) use of it, as it leads often to craete glorified hashes. Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors. If Perl had "better" parameter parsing, I can imagine Moo not being necessary, especially as Moo creates an accessor for everything even if what I really wanted was a named parameter in the constructor.

    Tadeusz put this into words far better than I can in How Moose Made Me a Bad OO Programmer.

      Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors.

      From my own practice, I can't confirm this (and I also heavily disagree with Tadeusz on the topic). When working with my old Moo(se) code, I find it very helpful that the modules have a clear optical distinction between the dumb data (the has () stuff) and the object methods which actually do things (the sub foo { ...; } things). Maintaining that distinction without Moo(se) needs more discipline than I usually have during my hacking nights.

      There is some truth in this if the objects are mainly just dumb data containers which don't have methods beyond the accessors. Not having to write code for these is a nice benefit, but you may put this into the category "fancy helpers for constructors". I find these container objects a lot when working with database-heavy stuff. And if the other side is a web application, decent parameter validation makes sense.

      I'm using other fancy helpers for constructors like coercion and BUILDARGS almost exclusively when I want to retain the API from a non-Moose constructor to avoid version dependencies.

      On the other hand, I have programs where attributes and accessors are almost exclusively used from within the module itself and external uses are through "higher level" functions. For such programs, object inheritance with its method modifiers and in particular roles play a much greater role than the constructor which in itself sometimes is used only internally, exposing factory functions to the outside. Users of these modules (well, mostly I myself) don't even need to know the attributes, but as a developer I'm happy to have them around for debugging.

      Hm, I am not a student of OOP theory, but I find that "most of what Moo faciliates" is not so much in the instance constructor but in attribute declarations, of which I typically have many times more than constructor params. I find that triggers, clearers, predicates and lazy builders etc. are among the main features of the framework, and they are for all attributes declared.

      I don't normally find a problem with having a RO "accessor" derived from declaring an attribute in order to take a named constructor param, but if you really don't want its value to be available to consumers you could maybe do something with BUILDARGS?

      package Foo { use Moo; has qux => (is => 'ro'); around BUILDARGS => sub { my ($orig, $class, $args) = @_; return { qux => $args->{bar} * $args->{baz}, }; }; }; use strict; use warnings; use feature 'say'; my $o = Foo->new({ bar => 6, baz => 7, }); say $o->qux; say $o->bar;
      Output:
      $ perl 11107488.pl 42 Can't locate object method "bar" via package "Foo" at 11107488.pl line + 24.

      Hope this helps!


      The way forward always starts with a minimal test.

        Yes, I could do that all in BUILDARGS, but "look at how tedious that is", when compared with doing the stuff as (fake) accessors. In a way this feels to me like Java where every data structure has to become a class.

        The following is a helper (role) that merely ingests either a premade dbh, or otherwise, a db username, db password and a DSN, to use DBI to make the DBH from:

        package Moo::Role::DBIConnection; use Moo::Role; use Filter::signatures; use feature 'signatures'; no warnings 'experimental::signatures'; use DBI; our $VERSION = '0.01'; =head1 NAME Moo::Role::DBIConnection =head1 SYNOPSIS { package My::Example; use Moo 2; with 'Moo::Role::DBIConnection'; }; # Connect using the parameters my $writer = My::Example->new( dbh => { dsn => '...', user => '...', password => '...', options => '...', }, ); # ... or alternatively if you have a connection already my $writer2 = My::Example->new( dbh => $dbh, ); =cut has 'dbh' => ( is => 'lazy', default => \&_connect_db, ); has 'dsn' => ( is => 'ro', ); has 'user' => ( is => 'ro', ); has 'password' => ( is => 'ro', ); has 'options' => ( is => 'ro', ); sub _connect_db( $self ) { my $dbh = DBI->connect( $self->dsn, $self->user, $self->password, $self->options ); } 1;

        Somehow, I think shouldn't have to make the dsn, name and password accessors just so I can use them from _connect_db, and ideally, there would be a nicer thing that implements what the Moo*-supplied ->new() does, except that it expects just a hashref, instead of expecting accessors on $self.

        But I haven't seen that yet, so it's not really a feature I'd want to see in Perl 7. If it happens for Perl 7 that would be doubly great, of course!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11107461]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2024-03-28 20:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found