develooper Front page | perl.moose | Postings from July 2011

Re: Moose documentation, "methods" and all that jazz...

Thread Previous | Thread Next
Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯
July 3, 2011 06:05
Re: Moose documentation, "methods" and all that jazz...
Message ID:
> accessibility to these attributes. What
> are the scoping rules?
Attributes do not have scopes per se. The instance variable has.

Moose being Moose, you can also add and remove attributes at runtime. The 
scoping rule then is "whatever the programmer likes".

> I couldn't find a non-trivial example as to how to write a useful method or
> how to INVOKE one in your script.
In this regard, Moose OO is not different than the unsugared OO you are 
already familiar with. You invoke with the `->` operator, see 
<>. The thread neighbours have already pointed out how to 
write one - not different than a subroutine.

> One example: You see a lot of "my $self = shift;" in the code examples of
> some methods, but not a single word about what is it, of what use is it and
> why do you need it.
It's the invocand. <> Again, this is part of 
the unsugared OO. <

> Another: You will fleetingly find terms such as "privately accessible..."
> (those entities with a name starting in an underscore?) and "publicly
> accessible..." (those that do not?). What do these mean?
It's merely a convention. In <> I 

| Prefix an identifier with an `_` to mark the function/variable etc. as
| private. This is documented in [perlstyle]( in the
| section about scope, about in the middle of the document.
| This is respected by sane programmers and some tools (source
| parsers/documentation), but not enforced by the compiler. See
| [perlmodlib#NOTE](

> Why do you need
> and where do you use one or the other?
You document to the user of your class that he should not access something you 
have declared private.

You as a benevolent programmer are presumed to not change the interface of 
your class (names of methods and attributes and their signatures, i.e. what 
sort of parameters they take) across minor versions. The users of your class 
rely on that the class works the same in v0.2 as in v0.1. For this reason, you 
want to keep the interface as small as possible, so that you don't need to 
mind a lot of stuff when you change something in your class. Conversely, you 
explicitely disavow that a private method could still exist in the next 
version. Maybe it will, maybe it will not. You see, this is some sort of 
social contract between you and the user. If he's so foolish to rely on a 
private method, he gets to pick up the pieces after his code broke due to a 
version jump.

So this is why you declare helper methods which are just used internally as 
private. OO is a manner of abstraction. You totally can replace the guts of 
your class as long as the interface stays stable.

> Can you "privately access" a
> "publicly accessible" entity?
That question does not make sense.

You can access public entities (methods, attributes). You can also access 
private ones (if you know the name, usually they are not documented and you'd 
need to go source diving), but you should not for the reason I laid out above. 
Bondage and discipline languages like Java enforce that privacy.

> In short, a lot to be desired...
You're just lacking a rigorous teaching of OO basics. The Moose manual 
explains Moose, not OO in general. Read a book or two, and the pertinent 
existing Perl documentation. Everything I wrote in this mail should already be 
known to an intermediate-level Perl programmer.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About