I am not sure why you are using attribute traits in the first place? Seems like you could do this with just plain old vanilla Moose. What do attribute traits give you that using cascading lazy builders would not?

My real code is quite longer/different, so I thought it would be better to post an example here.

My reasons: I found myself typing too much code each time I needed a special configuration class that represents a text config file and has functions to parse, validate (and in reverse also serialize) config entries.

So the idea was to define different config entry types ("file", "ip address", "email address") as traits containing a parser and a serializer function.
In the class representing the config file then I will only have to enrich the attributes with my traits to have a project specific config parser/writer:

has alarmMailsTo => (
    traits => ['ConfigEmail'],    # trait for type "email"
    conf_key => 'ALARM_MAILS_TO'  # associate with a config key
    isa => 'ArrayRef[Str]',
    is => 'rw',
);
[download]

A problem occurs when a trait needs some runtime information in it's parser/validator method. The problem and the workaround I have found by now is as follows:

Class that represents config file

..
with My::Config;

## some runtime information, eventually for the trait's method
has validDomain => (
    isa => 'Str',
    is => 'rw',
);

has alarmMailsTo => (
    traits => ['ConfigEmail'],
    conf_key => 'ALARM_MAILS_TO'
    attr_valid_domain => 'validDomain'  ## give attr name to trait
    isa => 'ArrayRef[Str]',
    is => 'rw',
);
..
[download]

Class role

..
role My::Config {
    method load() {
        ..
        ## $attr is a Moose::Meta::Attribute
        $attr->parse($self, $configString);
        ..
    }
    ..
}
[download]

Attribute Trait

..
role My::Config::ConfigEmail {
    has attr_valid_domain => (
        isa => 'Str',
        is => 'rw',
        required => 1,
    );
    method parse($instance!, $value!) {
        ..
        $instance
            ->meta
            ->find_attribute_by_name($self->attr_valid_domain)
            ->get_value($instance);
        ..
    }
    ..
}
[download]

(Btw. I actually have a "base trait" that contains the parse() method and all "type traits" consume it)

It works, but passing an attribute name to the trait and then passing an instance around seems not very elegant to me. Is there any other way to access the class instance from within an attribute trait method?

Thanks a lot for your help so far...
-maxhq

It works, but passing an attribute name to the trait and then passing an instance around seems not very elegant to me. Is there any other way to access the class instance from within an attribute trait method?

I would suggest actually that you not pass an attribute name, but instead pass a method name. Then if you put the method name into a common key like 'parameter_callback' instead of the more specific 'attr_valid_domain' you could likely move all the code up into the My::Config role. Here is an (untested) example of what I am talking about:

with My::Config;

## some runtime information, eventually for the trait's method
has validDomain => (
    isa => 'Str',
    is => 'rw',
);

has alarmMailsTo => (
    traits => ['ConfigEmail'],
    conf_key => 'ALARM_MAILS_TO'
    parameter_callback => 'validDomain'  ## give a method name
    isa => 'ArrayRef[Str]',
    is => 'rw',
);
..

## Class role
role My::Config {
    method load() {
        ..
        ## $attr is a Moose::Meta::Attribute
        my $parameter_callback = $attr->parameter_callback;   
        $attr->parse($configString, $self->$parameter_callback());
        ..
    }
}

## Base Attribute Trait
role My::Config::AttrBase {
    has parameter_callback => (
        isa => 'Str',
        is => 'rw',
        required => 1,
    );
}

## Attribute Trait
role My::Config::ConfigEmail with My::Config::AttrBase {
    method parse($value!, @parameters) {
        # now this is a more generic API
    }
}
[download]

This has a couple benefits:
1. Your parse API is now more generic and requires less knowledge of the outside world.
2. You can easily pass multiple parameters using the parameter_callback since it is just a method name. None of the other code will care if that code is an accessor to an attribute or a regular old method.
3. You now have room to grow with your parameters. If your $boss comes to you tomorrow and says "The configEmail role needs more parameters". you don't have to worry because you can just write a method to wrap "validDomain" and whatever the other parameter is. Then you just change the appropriate code in 'parse' and your done.
Of course, this is Perl so there is always more than one way to do it and there is nothing wrong with your approach really.
-stvn