in reply to Re^5: Module Organization
in thread Module Organization

Haha! Thats awesome! Thanks for showing it to me! I'm going to have to use that as an example for my code! +rep :D
The only problems that I have with reading that code are the +symbol, example: +? and I have no idea how to use has

has [qw( name type )] => is => "ro", isa => "Str", required => 1, ;
As I've never seen it anywhere... You mentioned that moose got hairy however I am told by others in this thread I should use it for my objects...also, is there a list of available terms anywhere for "is" and "isa" ?

Replies are listed 'Best First'.
Re^7: Module Organization
by Your Mother (Archbishop) on Oct 14, 2010 at 14:37 UTC

    If I had time I'd write up a full description and some comparisons of the techniques and idioms. I don't. :( The good news is the Moose docs are pretty darn good. Start on the main Moose page and then walk through as many of the Moose::Cookbook entries as you can.

    The + in the +shift->$method statements is probably too idiomatic to ask you to discover on your own.

    my $thing = shift; # ...is equivalent to... my $thing = shift(@_); # ...which is, except for altering @_, functionally equivalent to... my ( $thing ) = @_; # ...or... my $thing = $_[0]; # Perl really is your friend though! # shift without parens can become ambiguous to the interpreter, # not just the next developer! in some cases like... my $lookup = $hash{shift}; # not going to shift(@_) # the unary plus forces shift to be interpreted as the function- my $lookup = $hash{+shift}; # Quick proof- perl -le '%a = (1 => 2, shift => 4); print $a{shift}' 1 4 perl -le '%a = (1 => 2, shift => 4); print $a{+shift}' 1 2 # I think in the cases in the prototype code I showed you # The "+" is not necessary. I use it habitually to visually # disambiguate shift's usage as a function. # This all means that sub o_hai { my $self = shift(@_); return $self->get_some_val(); } # ...is the same as... sub o_hai { +shift->get_some_val; }

    Just so you know, many hackers here will tell you that this is suboptimal terrible style. They'd have a case. I find idiomatic Perl easier to read because it's more terse but it is also more confusing to those who don't know Perl idioms. So...

    Moose gets conceptually hairy; ask someone to explain the finer points of traits versus roles and the dangers of multiple inheritance to get a feel for that. Moose itself is a joy and, I argue, the clearest path through this problem space and I highly recommend it.

      I'm ahead of my class right now (they're going on lists) but it seems I'm unable to get them to install moose on the computers (something about the way the computer images every time the user logs off and on) so I'm stuck with regular OOP in class, sadly, which seriously hinders my will to use moose... :(

      I did install Moose on my home computer, though, so we'll see if I don't get anything out of that...

      I've got a problem visually thinking about the whole idea of the game loop, will be looking it up to see if there's anything to more readily help visualize it, as well as how to handle game//dungeon progression in the game.

      Some stuff I'm doing:

      Get the Game loop up

      Get some file handling going for persistent data

      Design inventory system as well as attribute system


      Here's some example code: Also, soon enough I'll have a CPAN Roleplay module up so that others can contribute if they want to help out, haha. Also, that magic +; came in from nowhere >.>