Attribute initializers - incorrect documentation

2010-02-04 Thread Karen Etheridge
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Hans Dieter Pearcey
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,

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Karen Etheridge
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Karen Etheridge
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Karen Etheridge
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Hans Dieter Pearcey
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Jesse Luehrs
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Hans Dieter Pearcey
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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Ricardo Signes
* Hans Dieter Pearcey h...@pobox.com [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

Re: Attribute initializers - incorrect documentation

2010-02-04 Thread Hans Dieter Pearcey
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.