Re: deprecated methods

[prev] [thread] [next] [Date index for 2004/11/26]

--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I think that something silly is happenning, that shouldn't be
happenning.

This probably has to do with the way perl caches calls as they were
resolved via @ISA.

I'd ask why this is happenning on perlmonks, and then perlbug if
there is no appearant reason.

Food for thought:

package foo; # for cleanliness

use Data::Dumper ();

sub fred { print "fred\n" }

print Data::Dumper::Dumper(\%{ __PACKAGE__ . "::" }, *fred{CODE});
print "can=3D", __PACKAGE__->can('fred'), ";\n";

fred;

undef &fred;

print Data::Dumper::Dumper(\%{ __PACKAGE__ . "::" }, *fred{CODE});
print "can=3D", __PACKAGE__->can('fred'), ";\n";

undef *fred;

print Data::Dumper::Dumper(\%{ __PACKAGE__ . "::" }, *fred{CODE});
print "can=3D", __PACKAGE__->can('fred'), ";\n";


This seems to be the way, but if we had a $fred it would be zapped too.

The C< undef &fred > is doing nothing to the symbol table itself, sort of l=
ike
undef $fred would zap the value of $fred but fred itself still exist (\$fre=
d is
meaningful).

I guess that's basically what happens, but i'm not sure it really makes sen=
se,
because subroutines don't change like variables, they are something else,
regardless of whether they're implemented in the same manner. IMHO at least=
=2E An
undefined value for code simply doesn't make sense. Either it's there and a
__PACKAGE__->can use it, or it ain't.

But this is perl, so i guess it is ;-)

I wonder what AUTOLOAD has to say about existing symbols with undefined val=
ues.


Anyway, that's my 0 input for today,

ciao!

=20
On Fri, Nov 26, 2004 at 17:25:35 +0000, Dave Howorth wrote:

> Perhaps I should add that doing the obvious cure of undefining the=20
> method doesn't work because UNIVERSAL::can() doesn't seem to notice. So=
=20
> even though the method has disappeared and causes an error when called,=
=20
> can() still indicates that it's there. So:
>=20
> #!/usr/bin/perl
> use strict;
> use warnings;
>=20
> BEGIN { print "can=3D", __PACKAGE__->can('fred'), ";\n"; }
> sub fred { print "fred\n"; }
> print "can=3D", __PACKAGE__->can('fred'), ";\n";
> fred;
> undef &fred;
> print "can=3D", __PACKAGE__->can('fred'), ";\n";
> fred;
>=20
> produces:
>=20
> Use of uninitialized value in print at test.pl line 5.
> can=3D;
> can=3DCODE(0x81199b4);
> fred
> can=3DCODE(0x81199b4);
> Undefined subroutine &main::fred called at test.pl line 11.
>=20
> All of which is as I would expect except the second can=3D line.
> Calling the code reference that can() returns also produces the=20
> undefined subroutine error, so can() really seems to be wrong (or more=20
> likely I'm being very dense :). It does get it right if I redefine &fred.
>=20
> I'm running Perl 5.6.1.
>=20
> Cheers, Dave
>=20

--=20
 ()  Yuval Kogman <nothingmuch@xxxxxxxx.xxx> 0xEBD27418  perl hacker &
 /\  kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!


--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBp3duVCwRwOvSdBgRAnmIAKC3f62MfRaj2QZMXoSVgqM+i0G63wCfcEBU
Rg0FMqj/5k3yh2adIHIL/jI=
=bbJW
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--