Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^5: Moose: What about "class" attributes?

by stvn (Monsignor)
on May 02, 2011 at 00:56 UTC ( #902409=note: print w/replies, xml ) Need Help??

in reply to Re^4: Moose: What about "class" attributes?
in thread Moose: What about "class" attributes?

Yes, pretty much exactly, except for one thing.

That could store the string in lexical variable that the instantiated role's code blocks are closed over, so it knows the value you told it.

Usually for stuff like this, I tend to prefer to make a static method to access the closed over data. Then any of my code uses the static method. It is still basically the same thing, but I prefer to not rely on closed over variables in the role block directly. (It also allows me to be really careful about my reference handling so as to avoid leaks, etc).

You may find as you delve into the world of MooseX:: that there are some plugins written in the early days of Moose which don't always take advantage of the current set of technologies. MooseX::Storage is a great example of this, it uses a hackish exported "Storage" function that will combine roles for you. If I were to write this today, I would use parameterized roles, but alas that module pre-dated MooseX::Role::Parameterized by several years and to convert it now would be a back-compat nightmare. And in the end, it still works perfectly fine so in this case, why fix something that ain't broke.

  • Comment on Re^5: Moose: What about "class" attributes?

Replies are listed 'Best First'.
Re^6: Moose: What about "class" attributes?
by John M. Dlugosz (Monsignor) on May 02, 2011 at 03:59 UTC
    I don't follow you on the advantage or reason for only using the closed-over variable in one place, that being a function that returns it.

    By "static method" you mean a sub that doesn't refer to any instance data (and would see the class name as the first parameter)? Is there a special technique for declaring those in a parameterized role or elsewhere? I did notice that using MooseX::Method::Signatures it doesn't like that as the first argument is checked against Object. But a regular Perl sub inside a code block (such as the role block) doesn't work right, so you must have some other way to declare that, right?

      I don't follow you on the advantage or reason for only using the closed-over variable in one place, that being a function that returns it.

      It is largely about scope management and making sure you control how many refs a given object might have. Here is some example (NOTE: I have not run this to confirm it works exactly as expected, but you should get the idea of you are familar with MooseX::Role::Parameterized)

      package My::Parameterized::Role; use MooseX::Role::Parameterized; parameter 'something' => ( isa => 'Str' ); role { my $p = shift; { my $something = $p->param('something'); method 'static_something' => sub { return $something; }; } }
      So, first let me say that this is likely overkill, but having had some nasty ref-counting leaks in the past I have learned to be cautious. So as you can see here, the 'static_something' method I am creating only closes over the $something variable, which we know is a string. If I had written 'static_something' like so:
      method 'static_something' => sub { return $p->param('something'); };
      Then the method would close over the $p object, which *might* become a source of leaks.

      Like I said, probably overkill, but I prefer to be cautious in this kind of environment.

        So the design of Param Role goes through all the trouble of making the params full-blown Moose Attributes rather than just arguments, and a parameter object rather than a hashref, but then you are careful not to close over either of them but only on plain values extracted from them.

        The docs show it would be my $something= $p->something. I didn't look to closely before, but now I'm not sure... I guess the parameter object $p is a Moose object that "has" the parameters specified, so ->something is the normal attribute getter for a ro attribute.

        Ref-counting leaks would be some kind of circular reference that the system is not tracking correctly. Or for whatever reason, the past existence of such leaks is why you are leery of closing over the complicated linked-up Moose objects involving anonymous classes.

        If I don't have the same penchant for making everything look like an accessor sub, declaring a lexical variable to hold the value returned from the param's accessor would do the same thing. OTOH, with your accessor method, only that one method needs to be a "closure", if Perl cares whether a closure is actually referring to anything that it might be closed over.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://902409]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (1)
As of 2021-04-18 00:47 GMT
Find Nodes?
    Voting Booth?

    No recent polls found