Re: attribute initialisation and after

On Mon, Oct 08, 2012 at 10:32:28AM +0100, Dave Howorth wrote:
> Chris Prather wrote:
> > On Fri, Oct 5, 2012 at 10:54 AM, Dave Howorth
> > <[email protected]> wrote:
> >> Jeff Hallock wrote:
> >>> Hi Dave,
> >>>
> >>> 'after' is called after a method call.
> >>>
> >>> If you want a block of code to be called every time you set an attribute, you want to use a trigger:
> >>>
> >>> has 'foo' => (
> >>>       is => 'rw',
> >>>       trigger => sub {
> >>>               # will be called when setting the attribute via 'new' or via the writer method
> >>>               my ( $self, $newval, $oldval ) = @_;
> >>>               ...
> >>>       }
> >>> );
> >> That's great. My code works now. Thanks Jeff.
> >>
> >> It does seem counter-intuitive. I'd expect
> >>
> >>   $o = Class->new(attribute => 'value');
> >>
> >> to have the same effect as
> >>
> >>   $o = Class->new(); $o->attribute('value');
> >>
> >> Anyway, at least it works and hopefully I'll remember the exception for
> >> next time.
> > 
> > I actually wouldn't, at least not anymore.
> 
> I'm afraid I don't understand what it is you wouldn't, given that it
> seems you would have before but won't now?
> 
> > Behavior and state while related are distinct. The call to new() is
> > passing in the new state for the object that is about to be created, I
> > wouldn't expect any extra behavior to fire there, and if it did I
> > would want it to happen explicitly (say via $self->attribute('value')
> > in BUILD method ... or via a trigger).
> 
> The call to new is passing in a new value for an attribute.
> The call to the mutator is passing in a new value for an attribute.
> I expect them to treat the new value in the same way in both cases.

But what if the attribute doesn't have a writable accessor? Being able
to set attributes in the constructor that then can't be changed after
creation is a very common pattern. If all constructor parameters had to
go through accessors, this wouldn't be possible.

This is also quite common in non-Moose classes - typically, constructors
will do something along the lines of

  sub new {
      my $class = shift;
      my %params = @_;

      return bless {
          foo => $params{foo},
          bar => $params{bar},
      }, $class;
  }

and what Moose does is not significantly different from this.

> > I can understand why you would have the expectations you have. I can
> > also understand why I have the expectations I have. 
> 
> I don't understand why you have the expectations you have. I'm not even
> sure I understand what those expectations are. Is there any
> documentation that explain what expectations are sensible to have for Moose?
> 
> (one thing I've noticed is that the documents start out by giving basic
> explanations of how to construct objects, and then more complicated
> explanations of what can be constructed, without giving any examples at
> all of how to use the objects.)

This is because once you create the objects, they should be usable just
as any other Perl object. If there is a place in the documentation that
you think could be improved, we are always open to documentation patches
- doc patches from new users tend to be very helpful because they still
know which parts are confusing(:

-doy