The problem is that package doesn't in and of itself introduce a new lexical scope so the previous $value (declared in the outer file-wide scope) is still valid. If you're trying to keep things grouped in the same file then wrap each package's contents in curlies so that there's a separate explicit lexical scope (or just put things in multiple files to begin with . . . :).

Update: Added parenthetical on file scope.

I take your point Fletch, but doesn't package introduce a new namespace - so perl should be able to distinguish between the instances of the new() subs ... shouldn't it ? ... or have I missed that boat as well ?
A user level that continues to overstate my experience :-))

Yes it introduces a new namespace, but again lexical variables have nothing to do with the symbol table and package variables. Maybe this and a reading of Coping with Scoping will help.

use strict;
use warnings;

## Define a lexical variable $foo (which will be otherwise unrechable 
+after
## the next our save by the closure)
my $foo = 'file lexical';

sub closure { print "closure says: $foo\n" }

print "before our: $foo\n";

## This masks the above lexical $foo for the rest of the outer file sc
+ope
our $foo = '$main::foo';

package One;

## And this masks the prior lexically visible $foo that pointed to $ma
+in::foo
our $foo = '$One::foo';

{
package Two;

## This $foo temporarily masks the prior $One::foo
our $foo = '$Two::foo';

print "inside package Two: $foo\n"
}

## Prior our $foo was scoped to the explicit block, so unadorned $foo
## once again means $One::foo . . .
print "back outside Two's block: $foo\n";

package main;

print "unadorned \$foo: $foo\n";

## But we can still explicitly refer to each of them by full package n
+ame
{
no strict 'refs';
print "$_: ${$_}\n" for qw( main::foo One::foo Two::foo );
}

## And now the sub closure is the only thing which has a handle on the
## original lexical $foo
closure();

exit 0;

__END__
before our: file lexical
inside package Two: $Two::foo
back outside Two's block: $One::foo
unadorned $foo: $One::foo
main::foo: $main::foo
One::foo: $One::foo
Two::foo: $Two::foo
closure says: file lexical
[download]

Update: Expanded example with more chattiness and a closure.

The cake is a lie.
The cake is a lie.
The cake is a lie.

As Fletch said, a namespace is not the same as a lexical scope...

This is important to keep in mind if you merge several modules (.pm files) into one file — for easy distribution, or whatever. Forgetting to put extra braces around each original file / package can introduce nasty subtle bugs... (in particular if the modules are coded sloppily, with lots of global vars, no strictures, etc.).

The behavior is mentioned in the package docs, btw:

(...) A package statement affects only dynamic variables--including those you've used local on--but not lexical variables, which are created with my.

    bless \( my $scalar ), ref $self || $self;
[download]

As I haven't got my copy of PBP in front of me, pls advise as to the preferred way.

TIA ,

A user level that continues to overstate my experience :-))

I don't know what PBP has to say on the matter, as its one of the few Perl books I haven't bought. But...

sub new {
    my $self = shift;
    bless \( my $scalar ), ref $self || $self;
}
[download]

Is better written as

sub new {
    my $class = shift;
    bless \( my $scalar ), $class;
}
[download]

You don't normally get a blessed reference passed into new(). If you're using my $foo = Object::Foo->new, or something similar, its the name of the class (Object::Foo in my example) that's passed into new(). So, my $class = shift; is more logical.

According to Wikipedia (and my personal understanding), cargo-cult programming is the superstitious inclusion of code that serves no purpose, merely for the sake of conforming to some remembered template. However, as you say in ref($proto) - just say no!:

Rather, I'm saying that "new" on an instance could mean either "clone" or "make new one like...", and thus you are confusing at least half your audience, guaranteed.

Thus you have already described at least two purposes of this construction. The fact that experienced OO programmers don't all agree on which purpose it should serve doesn't make the construct invalid—the idea that the existence of differing possible interpretations means bad code seems (to me) entirely counter to TIMTOWTDI.

Anyway: even if this construction is a bad, or at least inelegant, idea (which I think that it is), I don't think that automatically makes it cargo-cult programming.

sub value { $value }
1;    

package SVC::DnsEntity::IPv4;
[download]

zentara++ :-))

TFT zentara, I knew it would be so obvious I couldn't see it.

Thanx again

Update

Moderated zentaras kudos - when implemented, it didn't have quite the expected result...in fact, it didn't change it! :-(

A user level that continues to overstate my experience :-))

Doh...posted without testing. This works...wrap your packages in {}.

{
package whatever;

1;
}
[download]

---

I'm not really a human, but I play one on earth Remember How Lucky You Are

Once more I prostrate myself before you

Sounds dirty :P