Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

OO Perl Baby Steps

by Clovis_Sangrail (Beadle)
on Jun 12, 2013 at 15:22 UTC ( #1038492=perlquestion: print w/replies, xml ) Need Help??
Clovis_Sangrail has asked for the wisdom of the Perl Monks concerning the following question:

I am going thru the Alpaca book, currently trying out the examples of objects/instances. The packages (or classes) defined in the text are typically written as:

{ package somename; #perlcode }

I'm used to seeing things analagous to the 'package' keyword (ex 'sub') outside of the block of code. I find that Perl (or my example programs, at any rate) run identically with the syntax of the packages written as above (from the textbook) or in any of the following ways:

package somename; { #perlcode } package somename { #perlcode } package somename { #perlcode }; { package somename; #perlcode };

I do get syntax errors with the following:

{ package somename #perlcode }

When the package keyword is inside the block it seems you have to have a semicolon after the package/class name. But I am surprised that so many other variations all work. My question is, am I introducing some kind of subtle difference in scope or something like that? Are they really all the same?

Replies are listed 'Best First'.
Re: OO Perl Baby Steps
by davido (Archbishop) on Jun 12, 2013 at 15:39 UTC

    Your usages have subtly different semantic, and in some cases, practical meanings, especially if you're using Perl 5.14 or newer.

    { package somename; ..... }: This creates a lexical scope, and inside that lexical scope you happen to be working with package somename. When the block ends, you will be working back in the previous package again, though this is not the preferred syntax (see below) as of Perl 5.14.

    package somename; { ..... }: This declares that you're working with package somename, and then creates a lexical scope. The two are not really related to each other, but it does happen that this lexical scope was created while you're working in package somename.

    package somename { ..... }: This is a new Perl 5.14 feature; you've declared that you'll be using package somename for the duration of the following block (I suppose you could change within the block, but haven't tried). Once the block expires, the package you will find yourself working within will revert back to whatever was in effect before this package block.(See

    The next two are just the same as other constructs you demonstrated, but with an extra semicolon at the end, which has no effect. You can put a semicolon just about anywhere you want as long as it doesn't break a statement. print "hello world\n" ;;;;;;;;;;;;; print "Hello again\n";;;;;; # Perfectly legal

    The last one is a syntax error because you didn't separate the "package somename" statement from the next statement with a semicolon. It's not a syntax error if that statement is the last statement within the block, since semicolons are optional for the final statement in a block.


Re: OO Perl Baby Steps
by cdarke (Prior) on Jun 12, 2013 at 15:27 UTC

    In Perl, the semi-colon ; is not a statement terminator, as it is in languages like C, C++ and Java, it is a statement separator, as it is in Pascal and UNIX shells.

    So, the last statement in a block does not require a semi-colon after it. It is a good idea to put one in though, because someone (maybe you) later will add another statement and get a syntax error.

Re: OO Perl Baby Steps
by choroba (Bishop) on Jun 12, 2013 at 15:45 UTC
    package somename {
    is a recent addition (introduced in 5.14) and is equivalent to
    { package somename;


    package somename; {
    is different if there is some code after the closing } - it still belongs to the package.
    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: OO Perl Baby Steps
by Clovis_Sangrail (Beadle) on Jun 14, 2013 at 16:45 UTC

    Thanks, this is informative. I tested it out and saw that with "package pkgname;" just above the block of my parent class, I could move methods out to below the block of code and child classes could still inherit them. That's probably not a good idea. I guess the book's notation, with the package directive inside the block, is the most suggestive of the idea that the methods are specific to the class. That's probably what I'll stick with, and use 'package' statements outside of a block just for namespace (rather than OO Perl) purposes. But it's good to know about the new 5.14 syntax.

      Perl was not necessarily designed to be Object Oriented, and the addition of OO to Perl has been called by some a hack at best. If this concern of yours about packages is great enough then i instead invite you to use the declarative syntax for Moose, MooseX::Declare.


      (the triplet paradiddle with high-hat)

        I do want to check out Moose and MooseX (I'm tempted to call it 'Moose++'), it seems like alot of people use it. But I first want to get thru the, err, 'official' implementation of OO Perl as described in the Alpaca book.

        As I was reading the book and got to the section on closures, I thought to myself: "Ahh, this is how they are going to do private variables in a class." Then it turns out that it doesn't work that way at all. The private data is just all the fields in the whatever-it-is that the blessed reference references. And some people complain that it isn't as really private as they'd like.

        I'm surprised that there is not more use of closures. OTOH, maybe that would not work well with inheritance? In Googling about on the issue I see that I'm far from the first person to think about this. Well, exploring that question is likely much further over my head at this point than is Moose.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1038492]
Approved by marto
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2018-03-17 17:10 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (225 votes). Check out past polls.