Re: Attribute initializers - incorrect documentation
Excerpts from Ricardo Signes's message of Thu Feb 04 19:20:51 -0500 2010: > > They were rjbs's baby originally, but I don't think he's actually using > > them. > > FWIW, I am. LA LA LA LET'S GET RID OF INITIALIZERS What is it that they do that can't be done any other way? hdp.
Re: Attribute initializers - incorrect documentation
* Hans Dieter Pearcey [2010-02-04T14:58:50] > Triggers fire every time you set the value, including when it has a value > already. Initializers don't. > > I think that's it. > > They were rjbs's baby originally, but I don't think he's actually using them. FWIW, I am. It is insufficiently straightforward, right now, to do what they do without using them. I am happy to fix up code to use a sane alternative. -- rjbs
Re: Attribute initializers - incorrect documentation
Excerpts from Jesse Luehrs's message of Thu Feb 04 19:00:37 -0500 2010: > Figuring out how to do it isn't particularly obvious at the moment though. Yeah. I mean, I've done it; it's not that much of a pain. The pain is remembering all the places that need to be touched, let alone figuring it out if you haven't done it before. hdp.
Re: Attribute initializers - incorrect documentation
On Thu, Feb 04, 2010 at 06:46:21PM -0500, Hans Dieter Pearcey wrote: > Excerpts from Karen Etheridge's message of Thu Feb 04 15:43:05 -0500 2010: > > I'm satisfied now: there is no usecase for an initializer that couldn't > > be achieved using either a trigger or by modifying the behaviour of the > > attribute's setter. > > This may mean that we need to make it easy to inline such a set_value behavior > modification. I don't know how convenient it is now. It's not very hard, once you know how to do it. Figuring out how to do it isn't particularly obvious at the moment though. > (Inlining in general is not currently very accessible.) Part of the process includes a way to tell Moose to just not inline the modified accessors, if you're not comfortable with the inlining process, so this isn't as big of a deal. -doy
Re: Attribute initializers - incorrect documentation
Excerpts from Karen Etheridge's message of Thu Feb 04 15:43:05 -0500 2010: > I'm satisfied now: there is no usecase for an initializer that couldn't > be achieved using either a trigger or by modifying the behaviour of the > attribute's setter. This may mean that we need to make it easy to inline such a set_value behavior modification. I don't know how convenient it is now. (Inlining in general is not currently very accessible.) hdp.
Re: Attribute initializers - incorrect documentation
On Thu, Feb 04, 2010 at 11:58:10AM -0800, Karen Etheridge wrote: > Doh let me rephrase (of course they are different - trigger acts like an > 'after' method modifier on the setter, whereas initializer acts like an > 'around'). Is there anything one can do with an initializer that can't be > done with a trigger? If one wants to change the value of an attribute if a > particular value was assigned, one could simply call $attr->set_raw_value, > but that bypasses type coercion and some other nice things. Calling > set_value would cause an infinite loop in the trigger. > > The only other way through this that I see is to add a new meta-attribute > method set_value_without_trigger, but that's gross! doy set me straight: 12:34 < ether> so. after thinking through my post to the mailing list, I think there might be a use for initializers after all 12:35 < ether> there's no other good way of munging a value being assigned to an attribute, other than writing an explicit 'around' method modifier to the setter, and IMHO one should never have to depend on a setter's name 12:36 < ether> so what I'd do is simply change initializer so that it's always called on set, rather than just when $old_value is undef... if one passes $new_value and $old_value to the method, then one can still achieve the old behaviour if desired 12:37 <@doy> ether: accessor meta-trait 12:37 < ether> ah, to add on new behaviour in set_value? yes that would work 12:38 < ether> much better; thank you! I'm satisfied now: there is no usecase for an initializer that couldn't be achieved using either a trigger or by modifying the behaviour of the attribute's setter. -- Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
Re: Attribute initializers - incorrect documentation
Excerpts from Karen Etheridge's message of Thu Feb 04 14:53:50 -0500 2010: > Is there any behavioural difference between initializer and trigger methods > that I'm missing? Triggers fire every time you set the value, including when it has a value already. Initializers don't. I think that's it. They were rjbs's baby originally, but I don't think he's actually using them. hdp.
Re: Attribute initializers - incorrect documentation
On Thu, Feb 04, 2010 at 11:53:50AM -0800, Karen Etheridge wrote: > On Thu, Feb 04, 2010 at 02:17:32PM -0500, Hans Dieter Pearcey wrote: > > I'm not sure whether this is a bug or not, but we've been talking about > > giving > > initializer the axe for a while. Does anyone feel motivated by this to do > > so? > > I'm currently using an initializer attribute in $work code, to copy values > out of $obj->attr1 into $obj->attr2 (both are objects) when attr1 is set, > but I'm staring at the code again now and wondering why I didn't just write > a trigger instead. > > Is there any behavioural difference between initializer and trigger methods > that I'm missing? Doh let me rephrase (of course they are different - trigger acts like an 'after' method modifier on the setter, whereas initializer acts like an 'around'). Is there anything one can do with an initializer that can't be done with a trigger? If one wants to change the value of an attribute if a particular value was assigned, one could simply call $attr->set_raw_value, but that bypasses type coercion and some other nice things. Calling set_value would cause an infinite loop in the trigger. The only other way through this that I see is to add a new meta-attribute method set_value_without_trigger, but that's gross! -- "If you can talk brilliantly enough about a problem, it can create the consoling illusion that it has been mastered." - Stanley Kubrick . ... . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
Re: Attribute initializers - incorrect documentation
On Thu, Feb 04, 2010 at 02:17:32PM -0500, Hans Dieter Pearcey wrote: > I'm not sure whether this is a bug or not, but we've been talking about giving > initializer the axe for a while. Does anyone feel motivated by this to do so? I'm currently using an initializer attribute in $work code, to copy values out of $obj->attr1 into $obj->attr2 (both are objects) when attr1 is set, but I'm staring at the code again now and wondering why I didn't just write a trigger instead. Is there any behavioural difference between initializer and trigger methods that I'm missing? -- "Tolerance is giving to every other human being every right that you claim for yourself." - Robert G. Ingersoll . ... . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
Re: Attribute initializers - incorrect documentation
Excerpts from Karen Etheridge's message of Thu Feb 04 14:09:58 -0500 2010: > As mentioned on #moose yesterday, I have found an inconsistency in the > documentation (I don't think this is a "bug", as the actual behaviour looks > reasonable and correct to me): I'm not sure whether this is a bug or not, but we've been talking about giving initializer the axe for a while. Does anyone feel motivated by this to do so? hdp.
Attribute initializers - incorrect documentation
As mentioned on #moose yesterday, I have found an inconsistency in the
documentation (I don't think this is a "bug", as the actual behaviour looks
reasonable and correct to me):
The documentation for Class::MOP::Attribute 0.98 says:
This option can be either a method name or a subroutine reference. This
method will be called when setting the attribute's value in the
constructor. Unlike default and builder, the initializer is only called
when a value is provided to the constructor. The initializer allows you
to munge this value during object construction.
..but in fact the initializer is called at any point the attribute is set
(during construction, as well as after), as demonstrated by this simple
example:
package Foo;
use Moose;
has foo => (
is => 'ro', isa => 'Int',
initializer => sub {
my ($this, $value, $setref, $attr) = @_;
print "### in foo initializer!\n";
$setref->(2 * $value);
},
default => 1,
lazy => 1,
);
has bar => (
is => 'ro', isa => 'Int',
lazy => 1,
default => sub { shift->foo + 1 },
);
sub BUILD { print "### in BUILD\n"; }
1;
perl -I. -MFoo -we'\
my $obj = Foo->new; \
print $obj->dump(1); \
print $obj->bar; \
print $obj->dump(1)'
produces the output:
### in BUILD
$VAR1 = bless( {}, 'Foo' );
### in foo initializer!
3$VAR1 = bless( {
'bar' => 3,
'foo' => 2
}, 'Foo' );
--
Show me a piano falling down a mineshaft and I'll show you A-flat minor.
. ... .
Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
