Confirmed, this is a bug in Class::Field's implementation of fields.pm. 5.8.0's version does it right. I'll look into it, but don't expect anything soon as I've got my hands full working on stuff for 5.8.1.

I will most definately agree that fields.pm is a clumsy interface and would discourage its use in new code. Consider using something a bit more sophisticated. Class::Accessor, Class::Struct, Class::Class, Class::Generate... or whatever the state of the art for class generation and privacy is these days. I could also recommend a few simple tricks.

As for it being deprecated, or going to be thrown away, or in risk of having backwards compatibility problems in future versions of Perl, this is not true. Pseudo-hashes are going away, fields.pm is not. It will continue to work using restricted hashes. As long as you're using fields::new() and treating the resulting object exclusively as a hash you are safe.

Certain bits of fields.pm *are* going away. Anything that obviously exposes the underlying psuedo-hash is gone. That means fields::phash() and any time you assume your object is an array ref. %FIELDS will still be around, but don't trust that either.

On the flip side, using Hash::Util and lock_keys() directly means your code is tied to 5.8.0 and up. If you use fields.pm you can at least be backwards compatible. Hash::Util was not intended to be used directly in programs, it was thrown into 5.8.0 to have *some* user interface to restricted hashes upon which someone could write another more user friendly module around.

If you want to see how this all plays out, try a copy of bleadperl. All of the above has already happened. The current version of Class::Fields also already takes restricted hashes into account.

You can consider this semi-authoritative. I wrote Class::Fields, fixed and then killed pseudo-hashes, ported fields.pm to use restricted hashes in 5.9 and wrote Hash::Util. I have some experience with the subject. ;)