in reply to Re: Hiding Internal Classes ?
in thread Hiding Internal Classes ?

I really don't understand what you said. But, I find that methods can still be called when the symbol for the package is deleted. So, does that mean that blessing is symbolic after all? No, because a newly minted object does not work. So I suspect it's a cacheing thing.

use v5.6.1;  #ActiveState build 626
use strict;
use warnings;

package Foo;

sub bar { print "Foo::bar has been called\n"; }

sub new
 {
 my $s= 0;
 return bless \$s, "Foo";
 }
 
package main;

*newFoo= \&Foo::new;

my $x1= new Foo::;
$x1->bar();   # OK

print "before:", join (' ', keys %main::), "\n";
delete $main::{"Foo::"};
print "after:", join (' ', keys %main::), "\n";
$x1->bar();   # still works!

my $x2= newFoo();  # works
$x2->bar(); # can't find "Foo"

[download]

Replies are listed 'Best First'.
(tye)Re2: Hiding Internal Classes ?
by tye (Sage) on Jul 11, 2001 at 01:46 UTC

    Yes, methods are cached. Changing @ISA causes the cache to be invalidated except (apparently) for non-inherited methods. undefing or redefining the subroutine rather than the whole package is correctly handled by the caching code. I'm not surprised that the caching code doesn't expect people to undef the whole package. (:

            - tye (but my friends call me "Tye")
[reply]
      What's interesting is that $x2 doesn't have the cache like $x1 does. If the class is per-class, as I thought, then blessing it doesn't "connect" it to the cache yet.

      (I plead inocent! Undefing the package was not my idea.)

[reply]

        I think the cache is per-class but $x2 tries to look up the cache by name and can't find it while $x1 has a direct link to the cache whose name was removed when you undefed the package.

                - tye (but my friends call me "Tye")
[reply]

In Section Meditations