Stevan Little

lazy = $_->_fetch_data;

that just seems weird to me.. what is $_ in this case? I find this api to be a little weird compared to say lazy => 'fetch_data', or lazy => &_fetch_data;

submethod? is this going to be a strange way of saying private method?

will this new syntax perhaps allow parameters to lazy builders? I would love to have parameters to lazy builders. Motivation for this would be something like ... pass a database id, lazy load the object from the database, passing the id would not cause the lazy loader to be called, only an attempt to retrieve the object. (this may be a bad idea, impossible/impractical)

so "lazy" means, don't do this work until this value is requested (you know this but just for clarities sake). Also there are many ways to solve this particular example, I'm just thinking of yet another one.

So let's say I have an API integration with CouchDB or some other ROA+RESTful web service.

Here's how I could do this in Moose

package Order;
use Moose;

has _lwp => (is => 'ro', required => 1);

has _item_id => ( is => 'ro', isa => 'ArrayRef' );

has item => (

    is => 'ro',

    lazy => 1,

    default => sub { #uber shortened

       my $self = shift;

       my $res = $self->_lwp->get( $self->_item_id )

       Item->new( json_decode( $res->content ) );

    },

);

my $o = Order->new({ _item_id => 1 });

my $item = $o->item;

but it might be nice to be able to write

Order->new({ item => 1 });
my $item_obj = $o->item;
# or
my $item_obj = $o->item( 1 );

This looks remarkably similar to coerce from, except I don't want the coercion to be proactive. Don't do it until I ask for the value. Maybe what I want would be better described as lazy coercion. Although it seems to me that at some point I had a case for wanting an attribute (so I could cache the value easily, to have a parameter because I wanted to switch the response based on parameter, but not necessarily ever attempt to reload again )

Again, this may be a bad idea or out of p5-mop scope.

I notice in your example you do do { ... $item_id ... }. No need to call $self then? and $item_id is lexically scoped to the object instance?

Concerning the alternate approach to define a "required" attribute I must say that I really dislike the readability of this.

has $fetcher = die '$fetcher is required';

This codeline will suggest to the reader of the code, that we will die here, no matter what, we did not say that this attribute is required anywere.

I really prefer the more explicit approach of using a "is required" declaration, making obvious what the coder wants to achieve with this section of the code.

"has $fetcher = die '$fetcher is required';"

This works for me, I did get it right off the top, but then again I've lurked on the p5mop channel and look at the test case checkins. I see the value of not inventing new syntax plus I think (and stevan can correct me if I am wrong) one of the purposes of this blog was to explain how p5mop is taking a more clear approach to what required means. In Moose it was often an edge case to distinguish between not initialized and initialized but undefined. For p5mop it seems the choice was made to try and solve this off the top by using a more clearly declared intention. At first blush I think this is a good thing, given the number of times I've hit the edge case described. I do think though if we can find actual code reasons the approach is in question, Stevan would certainly hear it.

My first thought was to propose a trait:

class Cache {
    has $fetcher is default { die '$fetcher is required' };
    has $data is ro, lazy, default { $_->_fetch_data };

    method has_data { defined $data }
    method clear { undef $data }

    submethod _fetch_data { $fetcher->() }
}

And I like that a lot. I don’t think anyone could be confused over what this means. If you really chafe at the verbosity, maybe simply add special syntax for the builder, by making it an optional trailing code block?

class Cache {
    has $fetcher { die '$fetcher is required' };
    has $data is ro, lazy { $_->_fetch_data };

    method has_data { defined $data }
    method clear { undef $data }

    submethod _fetch_data { $fetcher->() }
}

Though in this case, binding $self within the builder rather than $_ does start to seem more natural…

Either way, using = to mean closure construction rather than assignment just weirds me out, because of the way Perl mixes compilation and execution. Consider the syntactically analogous …

package Cache {
    my $fetcher = die '$fetcher is required';
    my $data = $_->_fetch_data;

    sub has_data { defined $data }
    sub clear { undef $data }

    sub _fetch_data { $fetcher->() }
}

… in which Perl would throw an exception “on sight”. But inside class, on has lines, somehow assignment isn’t actually assignment.

Now I’d get used to it, sure. But I don’t think it’ll ever feel natural. Marking the code as a block, OTOH, IMO makes it naturally understood that it’ll run “at some point” and not necessarily when the declaration is executed.

So, I hope it's not too much off topic, but what I liked in Ruby, is that attributes variables have a leading sigil '@'. I don't like the syntax (the sigil), but I like the idea: it makes it obvious to the reader that the variable is not a simple lexical one. Can we ( pretty-please) have something like that ?

You know how some coders lack imagination regarding variable names

has $fetcher = ...

... 200 lines later ...

method foo {

  my ($fetchers, $fetching_data, $data_fetched, $fletch) = ...;

  $fetchers->($fletch, $fetcher->($fetching_data));

}

The example is stupid, but you see how it can be difficult to pinpoint the attribute. Which is IMO a very important feature of an OO syntax. Also, companies using Perl will then enforce "coding styles" that imply prefixing all attributes with "attr_" or something... Any thoughts ?

Rather than
"has $fetcher = die '$fetcher is required';"
I was hoping for
"has $fetcher || die '$fetcher is required';"

Is it true that that won't work because you have to allow for undef as an acceptable value?