

Wrapping An OO module in a procedural API using Exporter::Simple (perl) - f00li5h
http://f00li5h.pin21.com/blog/Wrapping-An-OO-module-in-a-procedural-API-using-Exporter::Simple.html

======
jrockway
A few thoughts. Don't do "package Foo; { ... }". Nobody else in the world has
ever done this. It's completely pointless and confuses people.

Use Sub::Exporter instead of Exporter::Simple. Bigger community, more testing,
more features. (Attributes? No thanks.)

Don't let your users use global variables and singletons. Don't make an OO
interface that needs a functional interface on top. Pick the right one for the
job. If there is state, it should be an object. If there is no state, it
should be a set of functions.

File::Spec is OO because someone was way too clever when implementing it, not
because it is actually OO. (The cleverness is that @ISA is changed to
File::Spec::YourOS at runtime, and then File::Spec->whatever delegates to
File::Spec::YourOS->whatever magically. This is clever, but not the best way
to implement that.) File::Spec::Functions is a band-aid on top of a flawed
design. Design your module's interface correctly from the beginning, and you
won't need to write 300 lines of hacks on top of it.

(This is why people hate Perl, because many people start using Perl, get
excited by super-amazing-awesome-cool features like changing your class's
inheritance hierarchy at runtime, and write confusing and unmaintainable code
when they could have _not_ used the cool feature instead. A lot of dynamic
language features are there for the very special 0.01 percent case. Your
program is probably not that, so just do it normally, see how you like it, and
go from there. With Perl, you _can_ write very clever code. Try not to.
</rant>.)

~~~
nathanielksmith
I agree. The issue is not "I do or do not want $instance->method() in my code"
but rather "Do I have state to encapsulate?"

I'm a full time perl programmer and often run into people from the perl
community who think OO is just a calling convention or a style instead of a
tool with a specific purpose. It's very frustrating. The fact that Perl's
native OO support is incomplete and obtuse just makes it worse. This module
follows that pattern of thought. Using it would just add arbitrary and
unnecessary complexity to a project.

~~~
f00li5h
I chose the logging because, log objects generally do not need to keep a lot
of state, and mentioned OO being "An idiom in which you capture behavior along
with state" but perhaps I could have expanded on it further.

If you don't like blessing refs yourself, use a module to hide the boring
repetitive parts like you would with any other problem...

I'm pretty sure perl5's OO falls into the simplest-thing-that-could-possibly-
work category, and obeys the "Rule of Separation: Separate policy from
mechanism"

