Stevan Little wrote:
You can apply roles like this:
with 'Foo';
with 'Bar';
It is not recommended because it will bypass the method conflict
checking, but it does work and is supported.
Interesting. Ok, I'll go that route. Thank you.
OTOH, I think there's going to be another policy added
You can apply roles like this:
with 'Foo';
with 'Bar';
It is not recommended because it will bypass the method conflict
checking, but it does work and is supported.
- Stevan
On Jan 19, 2009, at 10:09 PM, Elliot Shank wrote:
Stevan Little wrote:
This (IMO) is the perfect use case for the h
Stevan Little wrote:
This (IMO) is the perfect use case for the horizontal reuse of roles
because it allows you to inject commonly needed functionality into your
classes without forcing some kind of convoluted inheritance relationship
that does not accurately reflect your domain.
But this is
Oh, then that is easier I think.
Create a simple transformer function, put it into a role and have the
appropriate classes consume it.
This (IMO) is the perfect use case for the horizontal reuse of roles
because it allows you to inject commonly needed functionality into
your classes witho
Stevan Little wrote:
Have you looked at MooseX::MultiInitArg?
That works for assigning specific names to specific attributes, but doesn't address the thing that
I'm going after, which is formulaic. In my case, my BUILDARGS() makes the configuration keys case
insensitive and converts spaces t
On Jan 19, 2009, at 4:45 PM, Elliot Shank wrote:
I've got various classes that I'm initializing based upon hashes
that come from configuration files. The keys that come from the
files don't necessarily match the names of the attributes. Simple
enough-- that's the type of thing that BUILD
I've got various classes that I'm initializing based upon hashes that come from
configuration files. The keys that come from the files don't necessarily match
the names of the attributes. Simple enough-- that's the type of thing that
BUILDARGS() was created for. But the question is how to sh
Thanks, Dave. That's just what I needed.
On Mon, Jan 19, 2009 at 1:19 PM, Dave Rolsky wrote:
> On Mon, 19 Jan 2009, Dave Rolsky wrote:
>
> On Mon, 19 Jan 2009, Dan Harbin wrote:
>>
>> Log::Log4perl encourages you to maintain a hierarchy of loggers that
>>> matches
>>> your class hierarchy. I
On Mon, 19 Jan 2009, Dave Rolsky wrote:
On Mon, 19 Jan 2009, Dan Harbin wrote:
Log::Log4perl encourages you to maintain a hierarchy of loggers that
matches
your class hierarchy. I was achieving this by doing:
Log::Log4perl->get_logger(shift->meta->name). This works great except with
anonymo
On Mon, 19 Jan 2009, Dan Harbin wrote:
Log::Log4perl encourages you to maintain a hierarchy of loggers that matches
your class hierarchy. I was achieving this by doing:
Log::Log4perl->get_logger(shift->meta->name). This works great except with
anonymous classes since I can't turn on logging in
Dan,
That is not MooseX::Traits so much as it is just how role-application-
to-instances works (it must create an anon class to apply the role
to). Anon classes do share a common prefix though, so perhaps you can
use that?
- Stevan
On Jan 19, 2009, at 1:35 PM, Dan Harbin wrote:
Moose-pe
Moose-people,
I have a large system built with Moose objects and roles that is logged with
Log::Log4perl. Moose meets my needs well, and the functionality of
MooseX::Traits helps a great deal in making the system configurable.
My only quibble is that MooseX::Traits creates an anonymous class as
Yuval Kogman wrote (in private):
2009/1/19 Darren Duncan :
So, any similar hacks to help with that, prior to Moose roles being smart
enough to deal with this?
with delegation you can just put the role after the attribute declaration:
has foo => ( ..., handles => [qw(bar)] );
with 'Role::That
13 matches
Mail list logo
