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.
* 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 stra
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
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
>
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
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 w
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.
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
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
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 n
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 ref
11 matches
Mail list logo
