Wrapping An OO module in a procedural API using Exporter::Simple (perl)(f00li5h.pin21.com)
f00li5h.pin21.com
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
1 comments
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.
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.
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"
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"
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!
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!
In your end rant, you could replace "Perl" with just about every other language out there.
Absolutely. I mostly use Perl, so I feel I can speak most accurately when being specific.
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>.)