in reply to encapsulation via compiler-checked symrefs
Personally this is not a technique that I would use except in extremely unusual circumstances (obfu, golf etc) and would convert any code using such shenanigans to use real references before use, either that or not use it at all.package Mr::Rogers; use strict; my $r=__PACKAGE__; __PACAKGE__->{height}=200; #this is ok under strict for some reason $r->{age}=20; #this will die under strict;
Update
Something about this was bothering me, specifically which package was having its symbol table raped. With a bit of help from broquaint I figured it out, and it just makes me all the more against the very idea of this type of construct.
What exactly do you think __PACKAGE__->{age} in the above example is refering to? As in what hash in what package? I bet not what you think it is.
The answer of course is that it is creating a variable name 'Rogers' in the package named 'Mr'. While this may be what you thought and what you wanted it is very misleading. Anyone seeing the __PACKAGE__ token would expect things to be happening in the current package, but of course this is not so.
The reminds me of a little demonstration of naming implications. Get a bunch of differently coloured pens. Line them up and then write the name of the second pens color with the first pen, and so on for the rest, warping around for the last pen. Now try to recite the colors of each word quickly, over and over. Bet you make a mistake in first few words. Its even harder when they really are messed up.
Purple Yellow Blue Pink Red Green
Yves / DeMerphq
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)
|
|---|