Is there any difference between "standard" and block package declaration? - perl

Question

Usually, a package starts simply as
package Cat;
... #content
!0;
I just discovered that starting from the perl 5.14 there is the "block" syntax too.
package Cat {
... #content
}
It is probably the same. But just to be sure, is there any difference?
And about the 1; at the end of the package file. The return value of any block, is taken as the value of the last evaluated expression. So can I put the 1; before the closing }? To make require happy, is there any difference between:
package Cat {
... #content
1;
}
and
package Cat {
... #content
}
1;

Answer 1

Of course there is a difference. The second variant has a block.
A package declaration sets the current namespace for subs and globals. This is scoped normally, i.e. the scope ends with the end of file or eval string, or with an enclosing block.
The package NAME BLOCK syntax is just syntactic sugar for
{ package NAME;
...;
}
and even compiles down to the same opcodes.
While the package declaration is syntactically a statement, this isn't semantically true; it just sets compile-time properties. Therefore, the last statement of the last block is the last statement of the file, and there is no difference between
package Foo;
1;
and
package Foo {
1;
}
wrt. the last statement.
The package BLOCK syntax is interesting mainly because it looks like class Foo {} in other languages, I think. Because the block limits scope, this also makes using properly scoped variables easier. Think:
package Foo;
our $x = 1;
package main;
$::x = 42;
say $x;
Output: 1, because our is lexically scoped like my and just declares an alias! This can be prevented by the block syntax:
package Foo {
our $x = 1;
}
package main {
$::x = 42;
say $x;
}
works as expected (42), although strict isn't happy.

Answer 2

package Foo { ... }
is equivalent to
{ package Foo; ... }
which is different from the following in that it create a block
package Foo; ...
This only matters if you have code that follows in the file.
package Foo { ... }
isn't equivalent to
BEGIN { package Foo; ... }
I would have liked this, but that proposal was not accepted.
require (and do) requires that the last expression evaluated in the file returns a true value. { ... } evaluates to the last value evaluated within, so the following is fine:
package Foo { ...; 1 }
Placing the 1; on the outside makes more sense to me — it pertains to the file rather than the package — but that's merely a style choice.

Answer 3

There is a difference :) If you can try running below two different code snippets (just import the modules in a perl file )
# perlscript.pl
use wblock;
wblock::wbmethod();
First Code snippet without block, wblock.pm
package wblock1;
my $a =10;
sub wbmethod1{
print "in wb $a";
}
package wblock;
sub wbmethod{
print "in wb1 $a";
}
1;
Second with wblock.pm
package wblock1 {
my $a =10;
sub wbmethod1{
print "in wb $a";
}
1;
}
package wblock {
sub wbmethod{
print "in wb1 $a";
}
1;
}
Now the difference as you might have seen is, variable $a is not available for wblock package when we use BLOCK. But without BLOCK we can use $a from other package, as it's scope is for file.
More to say from perldoc itself:
That is, the forms without a BLOCK are operative through the end of
the current scope, just like the my, state, and our operators.

Answer 4

There is a difference but only if you are doing hard-to-maintain programming. Specially, if you are using a my variable across packages. The convention for Perl is to have only one package per file and the entire package in one file.

Answer 5

There's one other difference that other answers haven't given, that may help explain why there are two.
package Foo;
sub bar { ... }
was always the way to do it in Perl 5. The package BLOCK syntax of
package Foo {
sub bar { ... }
}
was only added at perl 5.14.
The main difference then is that the latter form is neater but only works since 5.14; the former form will work back to older versions. The neater form was added largely for visual neatness; it doesn't have any semantic difference worth worrying about.