We were presenting the users with lists and they needed to select one or more items from those lists.

It seems to me that the appropriate place for my %is_selected; is inside the code that presents the list to the user and lets them select one or more items. And that code should know how to return the list of selected items (that code might be encapsulated in a class, depending).

The problem with free'ing the %is_selected is just one symptom of a poor solution that doesn't scale. Consider if you need to select more than one set of servers. You only have one is_selected() method per object. But if you present the user with the opportunity to select a subset twice, then by putting the information about what they selected in a more appropriate place, there is no problem if you need multiple subsets selected (and this information is deleted when you are done with it).

The problem with free'ing the %is_selected is just one symptom of a poor solution that doesn't scale.

The problem with freeing that is a problem with adding traits to a language which doesn't natively support them. It has nothing to do with whether or not the concept is appropriate.

As for the rest of what you typed, it might be a great way of looking at the problem but it's completely irrelevant to my specific coding problem. With runtime traits, my code is cleaner and easier to read. Solutions should be created to match actual problems faced, not "what if" scenarios -- unless those scenarios have a realistic chance of occurring. For the purposes of the code I was working on, it's been used for years and is quite stable. Your scenario is highly unlikely to apply.

Cheers,
Ovid

New address of my CGI Course.

@servers = map { $_->{selected} ? $_->{obj} : () } @servers;
[download]

That is just ugly for a variety of reasons, ... In fact, the map statement could probably be written more clearly as follows:

@servers = map  { $_->{obj} }
           grep { $_->{selected} } @servers;
[download]

That’s easier to read, but it’s still pretty ugly.

    package Trait::Selected;
        use Object::InsideOut;
        my %is_selected :Field :Acc(is_selected);
[download]

Class::Trait->apply( $some_class, 'Trait::Selected' );

    My::Class->add_class('Trait::Selected');
[download]

What happens when the object goes out of scope? The trait still retains that object’s selected value and it’s tricky to remove.

I just uploaded Object::InsideOut v2.08 (which contains the runtime inheritance feature) to CPAN. Thanks for the idea.

Bink! That piques my interest. Can't wait to see it out there and I'll start playing with it. Maybe that's enough to get me over the learning curve hurdle. Thanks!

Cheers,
Ovid

New address of my CGI Course.

With all this applying of runtime traits are you noticing that your ISA cache is nearly always invalid or what? When you apply a trait to an object does it make a class or what?

Don't know why my reply didn't show up. I'll try again.

The ISA cache isn't invalidated (that I'm aware of) because when applying the trait to a class, ISA isn't affected. The methods get compiled directly into the class. As for applying a trait to an instance, I follow the Perl 6 route and make a new anonymous class. That alters ISA and if I layer on several runtime traits it might be a problem, but for the most part, it's not caused me any difficulty.

Cheers,
Ovid

New address of my CGI Course.

Compiling a new method also clears the cache but that doesn't really matter since I expect there's a limited number of classes that this is happening to and it's not a "runtime" thing. Its when you go clearing your cache at runtime that you get perl's OO to start losing that 30-40% performance vs functions that we used to hear so much about. I've understood that it's all the having to do ISA method lookups that made perl OO slow and applying this stuff to objects during rumtime is buying that problem back again.

But then elegant solutions are also very nice for a programmer and that might be more expensive yet than the CPU time.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

It seems like this is a lot of effort to modify the objects instead of fixing the initial data structure used to track selections. For example, why not just add selected items to a Set::Object? (Or, for lower tech, just an array.)

use Set::Object;

my $selected = Set::Object->new;    # create set
$selected->insert( @some_objects ); # add objects
@servers = $@selected;              # get them back
[download]

What happens when the object goes out of scope?

You're using something like the inside-out technique with all the usual problems cleaning up afterwards. You could wrap the primary class' DESTROY method (or add one) to clean up the trait and then continue with destruction.

When it comes to maintaining state I don't see much difference between runtime trait and statically applied trait. As far as I remember the original paper the traits are stateless by nature. So IMHO what you try to do is breaking the traits :-)

But your need is also very natural. I often use Class::Trait and many of my traits would like to have their state variables (usually class or instance accessors).

I solve their wish by a subroutine in the trait (currently named build_class) which I call immediately after the trait is applied. The build_class then modifies the class according to trait's needs.

Class::Trait->apply( $some_class, $some_trait );
my $build_class_sub = $some_trait->can('build_class');
$build_class_sub->($some_class);
[download]

Inside the trait I have, for example:

sub build_class {
   my ($class) = @_;

   $class->mk_accessors( qw(smb_hostname) );
   $class->mk_accessors( qw(smb_username) );
   ...
}
[download]

I guess that with your inside out approach you would probably need something like:

sub build_class {
    my ($class) = @_;

    my $destructor = sub {
        my ($this) = @_;
        delete $is_selected{ get_obj_id($this) };
    };
    $class->register_destructor($destructor);
}
[download]

I know that this approach is not very traity, but my primary goal is to find a consistent and clear way to build my classes not to use pure traits.

There is also somehow complementary issue I need to solve with traits: fixing the name of applying class in the trait. In other words I need my __PACKAGE__ in the trait.

Imagine few logging functions - perfect task for traits. One of them is the logging path for the module. Implemented in class it would look like:

sub logpath {
    my ($this) = @_;

    return File::Spec->rel2abs( join( '-', split /::/, __PACKAGE__ ) .
+ '.log',
        $this->log_root );
}
[download]

All subclasses log into the same file as the class which defined the method. My Durian::Call::Statement logs into $ROOT/Durian-Call-Statement.log as does its Durian::Call::Statement::Incoming subclass.

But how to accomplish this task with trait? The only way I found is to modify the trait symbol table with respect to the class applying the trait immediately before the application. In other words apply a slightly modified trait to every class.

To call preapply subroutine right before the trait methods are collected.

sub preapply {
    my ($class) = @_;

    *logpath = sub {
        my ($this) = @_;

        return File::Spec->rel2abs( join( '-', split /::/, $class ) . 
+'.log',
            $this->log_root );
    };
}
[download]

With respect to preapply the better name for build_class would be postapply. It sounds good, doesn't it?

Unless someone explains to me that it is a very bad idea I'll try to make my own preapply/postapply Class::Trait subclass.