... At this point i'm not sure if i'm repeating myself or not ...

q{ You have an odd notion of what's "clean" }. This is true, I learnt perl by reading merlyn's (et al) llama and TheDamian's Perl Best Practices, so I suspect that my view may be a little tainted by what I've been told is "just the right way to do it".

Yes, you do get stuff from the SYNOPSIS the first time, but after that, you should be able to guess the interface of the module, getters, setters and all should become fairlly obvious to guess after a short period of use.

q{ Well, different things should look different, right? }. Yes this is true, a constructor should look like one, and a setter method should look like one. Things should look different, but if something is wrong, it should always look wrong.

$f00li5h = f00li5h->new();
$f00li5h->{moose};        # looks wrong because my objects never work 
+that way
$f00li5h->get_moose;      # *magic*
$f00li5h->set_moose( 8 ); # *magic*

$doom  = Doom->new();
$doom->get_moose;         # looks wrong - your objects don't work like
+ that
$doom->{moose}            # wrong-o
$doom->moose;             # *joy* this is the ticket
$doom->set_moose( 21 );   # looks right to people who often use doom's
+ objects
[download]

I'd say that their looking similar makes for a uniform interface... also:

$f00li5h->get_foo;
$f00li5h->set_foo('new value');
[download]

$f00li5h->{moose}; # looks wrong because my objects never work that way

But... isn't that a "surprise"? Doesn't everyone expect perl objects to work that way? How can you deviate from the standard without creating mass confusion?

Doesn't everyone expect perl objects to work that way?

Mine don't. Mine work as I documented them. If you use them in ways apart from that documentation, things will break and you get to keep all of the pieces.

The same rule applies for most other modules.

q{ But... isn't that a "surprise"? }. This is a fair point, but it's only a surprise if the user of my class expects a hash based implementation (the docs will soon correct this faulty guess ^_^).

In the case where he looks into my hash, he has decided to play with the underlying implementation details of my class and that's none of his buisness. It means I can't change how my classes work without breaking his client code, it also ties his code far tighter to my class and it's implementation, so he wont be able to later (painlessly) change to f00li5h::XS to gain the speed improvements it offers, or f00li5h::POE::Plugin to gain the cool poeness. Also, I may not be able to maintain a hash based interface when writing these new versions, so they may just never happen.

At very minimum, letting people play with your hash innards is using variables in your API, and that's frowned upon.

Although tricks with tie can allow my code to look like it's based on a hash, when it's not (kyle's Make an inside-out object look hash-based using overload.), but that's really best for porting, not for long term use...

@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;