class collector {
    has @.state;
    method collect(Int *@nums){
        self.state.push: @nums;
    }
}
[download]

In fact for the example you have given a simple array is enough, but I assume you want to do a bit more in collect.

The idea of OO is to bundle data with the methods that work on it, now you suggest to bundle a "state" with the method that works on it - for me it sounds like that's the same, or at least that it can use the same abstraction - classes.

And I don't quite see the overhead in writing classes - snytactically that's class, a name and two curly braces.

(Updated: fixed missing brace)

class collector {
    has @.state;
    method collect(Int *@nums){
        self.state.push: @nums;
    }
}
[download]

Well, you see? When seeing code like this I would ask myself: why did the author need the full power of a class? To use it, I would need method calls, which makes for more clumsy syntax: this would be appropriate where... it would be appropriate. But really I'm thinking of a situation where a simple sub with a state variable is best suited: they do exist, right? So why should one not use them? Point is, since state variables maintain their state across calls, they're not "that" internal to subs anymore, and for one reson or another one may want to to give a peek at them. If you think of it, even in Perl 5 you can do

{
    my @state;

    sub collect {
        push @state, @_;
    }

   sub state : lvalue { @state }
}
[download]

If you look at it, and consider that you won't need the class name in calls, it looks and behaves much like your class, except without "something more" that serves no real purpose here.

Perhaps having all state variables automatically map to public attributes is too much and some care should be taken so that one would do so only knowing what she's doing, perhaps by means of a trait:

state $count is visible;
[download]

In fact for the example you have given a simple array is enough, but I assume you want to do a bit more in collect.

Needless to say.

The idea of OO is to bundle data with the methods that work on it, now you suggest to bundle a "state" with the method that works on it - for me it sounds like that's the same, or at least that it can use the same abstraction - classes.

Yep, in fact TMTOWTDI - as I said it's all about a shortcut and syntactic sugar to make some things practical: with state variables, in my view a sub does Code and does an anonymous class which has precisely those public attributes.

And I don't quite see the overhead in writing classes - snytactically that's class, a name and two curly braces.

But when you call the methods, you have collector.collect and collector.state: as I said I can see perfectly well why this would be appropriate in some situations. But there other ones in which I want a simple collect and access something that belongs to it. (But it wants to share, as above.)