I've done so carefully before posting, and as far as I can see the interface (fields::new()) and features are still the same. The only difference is that field access is no longer faster in 5.10, as I stated above.

So I'm still wondering: if one has to use plain blessed hashes, is there any reason not to get some static checks with fields?

---

Anonymous, holli and dragonchild: I'm perfectly aware of the benefits that come with modern OO frameworks, as I use Object::InsideOut in my own projects. However, for various reasons that I don't want to discuss on a public forum, I cannot use them here (openly or otherwise).

It's fine to use this module, although things like Class::Accessor are generally more popular. However, don't expect any compile-time checking and don't use that "my Type $foo" syntax since that's all pseudo-hashes.

If you want static checks, don't use fields. Use something like Tie::Hash::FixedKeys.

use Tie::Hash::FixedKeys;

my @keys = qw( a b c );

sub new {
    my $class = shift;
    my %args = @_;

    my $self = {};
    tie %$self, 'Tie::Hash::FixedKeys', @keys;

    foreach my $k ( @keys ) {
        if ( exists $args{$k} ) {
            $self->{$k} = $args->{$k};
        }
    }

    return bless $self, $class;
}
[download]

Now, you have all the benefits of static fieldname checking without going into the depths of a deprecated feature. Maybe it's just me, but I'd strongly prefer that.

Of course, the better solution is to create your own OO framework that auto-generates mutators based on some static list of mutator names. Writing one is the matter of a couple hours. You can even crib heavily from CPAN and call it your own work. That way, everything is a method call. Direct attribute access is horrible practice.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

I have to stick to [ ... ] classic blessed hashes for the implementation.

Most CPAN authors that I have worked with (and myself, for that matter) aren't really sticklers to "Use my version or else!". As long as you credit the author(s) in a comment somewhere in the code, that's all that's needed. I do that whenever I grab code from Perlmonks. Something along the lines of:

# Taken from http://www.perlmonks.org/?node_id=5551212
# Thanks to <userid> for providing it!
sub foo {
    # Some useful code here
}
[download]

An issue in perl 5.10

From fields:

Field names that start with an underscore character are made private to the class and are not visible to subclasses. Inherited fields can be overridden but will generate a warning if used together with the "-w" switch.

This is however only the case for perl 5.8. Consider the following code (in separate files as base borks if they are in the same script):

These tests pass on Perl 5.8.8, most likely because of the pseudo-hash implementation. However, on Perl 5.10 _f is shared between Base and Derived, and base() always returns the same as derived().

What's more, the documented warning is emitted only for public fields, so Perl stays silent here, while it would croak had I named my field f. This sounds like a bug, I'll try to report it when I have some free time.

In the end, I think that fields are still usable, but unless (until?) this issue gets resolved, private fields are best implemented as

sub PKG() { __PACKAGE__ }
...
    $self->{PKG.'.foo'} = 42;
[download]