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.)

In reply to Re^4: [Perl 6] State variables as public attributes? by blazar
in thread [Perl 6] State variables as public attributes? by blazar

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.