Wrapping An OO module in a procedural API using Exporter::Simple (perl)

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

by f00li5h • 16 years ago

18 6 16 years ago

f00li5h.pin21.com

jrockway2• 16 years ago

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>.)

f00li5h2• 16 years ago

package Foo { } is more or less a typo... and "Sub::Exporter - the way cool kids export custom methods" is under related reading at the end.

That's some fascinating history there... I did wonder why the heck someone would implement that as class-static functions...

/me notes that his project is not a beautiful and unique snowflake, but the decaying program code as the rest of us....

Also, thanks for the feedback!

nathanielksmith• 16 years ago

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.

f00li5h2• 16 years ago

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"

supersillyus• 16 years ago

In your end rant, you could replace "Perl" with just about every other language out there.

jrockway2• 16 years ago

Absolutely. I mostly use Perl, so I feel I can speak most accurately when being specific.

Wrapping An OO module in a procedural API using Exporter::Simple (perl)

Related Stories