use Perl

sub name {
    my $self = shift;
    return $self->{name};
}

then in your other methods in the class, go ahead and use the accessor directly, with

sub foo {
    my $self = shift;
    print $self->name;
}

instead of

sub foo {
    my $self = shift;
    print $self->{name};
}

There are a number of reasons for this, and you don't have to be a Java object purist to appreciate them:

• You can't use inheritance.
  What if you have a subclass of your class, and it overrides the name() method, but not the foo() method? You won't be using the overridden name()
• You're making a permanent assumption that the accessor will always be simple
  What if somewhere down the road you do some manipulation inside name()? Say you want it to return a proper-cased string. Now you're going to either replicate that code to proper-case the string, or you're going to go and change your uses of $user->{name} to $user->name anyway.
• Using your own accessors tests them
  What if your accessor is broken somehow? You'll never know.
• You're tying your code to the specific implementation of your object.
  Objects don't have to be hashes: Maybe you want to change to use an array, like in WWW::Mechanize::Link.
• You're tied to the naming convention
  Maybe you want to change the internal naming convention. You shouldn't have to go retrofit your code to do so.

Heck, accessors can even reduce punctuation: $user->name vs. $user->{name}.

There is only one reason to not use your own accessor methods, and that's to microoptimize your code for speed. If you've gone ahead and profiled your code, say, with Devel::DProf, and you know that calls to your accessors are causing a significant slowdown from overhead, and you've eliminated other sources of speedup, and you comment your code explaining WHY you're using the attributes directly, then sure, go ahead. We had to do this in MARC::Record in some tight-loop intensive code, but even then we changed some internal representations that bypassed the accessors entirely to get even more speedup.