Here be dragons, I think. Especially if you're doing this in a module that other people are going to use without worrying about the details of your implementation. I think you maybe ought to put some big hairy warnings in your documentation to the effect that your objects won't necessarily play nicely with code that treats them in unexpected ways (such as Clone::PP, which is *extremely* useful in a wide assortment of situations but might result in objects that are not on your list).

Of course, I could be mistaken. I don't actually know, for example, how Clone::PP works internally, but that's just what came to my mind off the top of my head. Whether that's one of them or not, it seems very likely to me that there are ways in which your list of objects of the class might get broken.

I'm hoping against hope that Perl6 will have an object forest like Inform has. If so, that would make it possible to walk through every object in the forest and check each one to see if it's a member of the class in question. (This would not be terribly efficient, but it would be possible. Inform programmers do it from time to time, for one reason or another. Though in Inform there's no list of objects on the forest floor, I would imagine that Perl6 would provide this, if it goes to the trouble to implement he forest in the first place. Inform also provides a way to enumerate every object in existence, irrespective of its position in the forest, but that is due to a lowlevel implementation detail and I would *not* expect Perl6 to have that. Which is the main reason I would expect it to keep a list of all the toplevel objects.)

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]