Moo/Moose attributes - how “keys %$self” works?

Question

In my last question I asked many unrelated things, and can't accept multiple answers what answers only some questions, so here is clearly (i hope) defined question about the (Moo) attributes.

use 5.010;
use strict;
use warnings;

package SomeMoo;
use Moo;
has $_ => ( is => 'rw', predicate => 1) for (qw(a1 a2 nn xx));

package SomeMoose;
use Moose;
has $_ => ( is => 'rw', predicate => "has_".$_) for (qw(a1 a2 nn xx));

package main;
use Data::Dumper;
my $omoo   = SomeMoo->new(a1 => "a1val", a2 => "a2val", xx=>"xxval");
say Dumper $omoo;

# $VAR1 = bless( {
#                 'a2' => 'a2val',
#                 'a1' => 'a1val',
#                 'xx' => 'xxval'
#               }, 'SomeMoo' );

#for Moose:  
my $omoose = SomeMoose->new(a1 => "a1val", a2 => "a2val", xx=>"xxval");
say Dumper $omoose;
#as above, only blessed to package 'SomeMoose'.

#in both cases can do the next, for getting an (partial) list "attributes"
say $_ for keys (%$omoose); #or %$omoo

#anyway, in Moose i can
say "all attributes";
say $_->name for $omoose->meta->get_all_attributes();

#what prints
# all attributes
# nn
# a2
# a1
# xx

So the blessed object refences an object what contains only attributes what are set.

Question:

• why the $self references, (so the %$self conatains) only the attributes what are set, and not all, e.g the nn too from the example code? (When the bless only associates the reference with an package why the $omoo isn't contains all package variables?) And from where the Moose knows it?)
• how to get all_attributes in case of Moo?

Clearly I missing some basic knowledge.. :(

Answer 1

why the $self references, (so the %$self conatains) only the attributes what are set, and not all, e.g the nn too from the example code? (When the bless only associates the reference with an package why the $omoo isn't contains all package variables?) And from where the Moose knows it?)

Each time you create a new object, such as SomeMoo->new, you create a new reference which is made of two parts, the first is the data, which is usually a hashref, that hashref is blessed by the second part, which is the class, SomeMoo. The hash is used to store data associated with this instance of the new object, while SomeMoo is the class which provides the methods associated with with accessing/manipulating/doing stuff with the data.

Inside your class definitions you call a function called has. This function extends the class with new methods. In the case of Moo, you could make a poor man's version, by writing something like:

package SimpleMoo;
no strict 'refs';

sub new {bless {}, $_[0]} # very very simple constructor (oldskool)

*{__PACKAGE__."::$_"} = sub {              # fyi: __PACKAGE__ eq "SimpleMoo"
    $_[0]->{$_} = $_[1] if exists $_[1];
    return $_[0]->{$_};
} for qw(a1 a2 nn xx);

The above add all our methods to the SimpleMoo class, it does so via manipulating the symbol table, and is probably quite close to what Moo does (except Moo/Moose extends a meta class which your class inherits from), an even simpler example would be to define the accessors manually:

package SimpleMoo;

sub new {bless {}, $_[0]} # very very simple constructor (oldskool)

sub a1 {
    my ($self) = shift;
    $self->{a1} = $_[0] if exists $_[0]; # set value if provided
    return $self->{a1}; # return the value
}
sub a2 {
    my ($self) = shift;
    $self->{a2} = $_[0] if exists $_[0]; # set value if provided
    return $self->{a2}; # return the value
}
# ... copy and paste the for nn and xx ...

As you can see from the examples above, I am extending the class with methods that allow you to set and get values from the hash, but not implicitly setting up the hash structure as part of the object's constructor (which should take place inside new if you want to do this) - just like Moo and Moose.

This means that inspecting the object via something like keys %$omoo doesn't show any keys until they've been set (either via the call to ->new or by setting them with $omoo->a1("someValue").

As mentioned by ikegami, adding something like: default => undef to your has statements will cause Moo/Moose to instantiate the value when the object is first constructed.

I hope this explains how $self contains the object data, which contains only keys previously set by methods or constructors.

how to get all_attributes in case of Moo?

Unfortunately the Moo api provides no method to list all defined attributes so I cannot offer a supported solution, but may I offer one of many (non-perfect highly un-recommended) solutions:

package SimpleMoo;
use Moo;
our @attr_list;
sub my_has {push @attr_list, $_[0]; has @_}
sub get_all_attributes {@attr_list}
my_has $_ => ( is => 'rw', predicate => 1) for (qw(a1 a2 nn xx));

package main;
my $omoo = SimpleMoo->new();
say $_ for $omoo->get_all_attributes;

I'm sure someone from Moo, will be able to provide a better way of accessing the meta class used in Moo to get this list. But I'm sure either solution is not recommended.

Ultimately, you are using Moose and Moo, you shouldn't be inspecting the underlying object, both modules use magic (symbol table modification and class inheritance, and all sorts) and you cannot rely on the underlying object nor the class itself to have the attributes and methods you expect them to have. if you have a use case where you want to list every attribute defined on a class, use Moose and inspect the meta class, or take control of you class by defining it yourself by hand.

You should also consider why you need a list of attributes from an object, perhaps you could list them yourself? what if someone inherits from your class? or you decide to mixin a role? would this break whatever code was trying to utilise a list of attributes on your object?