::NonOO suffix for non-OO version of a module
I wrote one this morning: Number::Closest::NonOO is the non-OO version of Number::Closest (plus with some additional features).
Is there an existing convention for this? Or can you suggest a better candidate? Can't seem to find or be able to come up with any. ::Simple is too vague (and a bit misleading). ::Functional? ::Function? ::Procedural? ::NonMoose implies an OO version but without using Moose. NOO is not immediately obvious.
Dear God...
my $finder = Number::Closest->new(number => $num, numbers => \@num) ;
my $closest = $finder->find; # finds closest number
All that, plus Moose, to do a bit of subtraction and sorting? How about
@closest = sort { abs($a-$num) <=> abs($b-$num) } @num;
As the saying goes, 90% of everything is crap, and this is clearly part of the 90%. I would suggest politely contacting the author and politely telling him that his module is not useful.
I added some handling of infinites (e.g. inf will be closest to inf and larger positive numbers, -inf will be closest to -inf and larger negative numbers).
Not to say that my module is useful :-), as this one is just an exercise without prior practical need.
I like the "I wrote and uploaded this thing to CPAN, now I'm looking for a good name for it." - why not blog *before* that? Did you email the module-authors list as well? Have you consulted people on IRC? Anything before uploading this?
Well, to be honest I did post this blog post just *before* finishing and uploading the module to CPAN. :)
The File::Spec and File::Spec::Functions namespaces comes to mind. I had this idea for NoOO, though :)
But, so much negativity today and not a direct answer among them. Nobody needs to get anyone's permission before they play around with Perl, certainly not from the IRC mafia. Maybe only 10% of stuff is good, but maybe that also means we need more 90% to get more 10%. CPAN has the philosophy of upload early and upload often. We want to capture as much value as possible and get people going as quickly as possible. We can refine later, and in a collaborative way. If you don't want to help, save yourself the hassle of replying so you can add value to whatever you think is good. :)
Most things we do don't really need modules because they aren't that complicated, but we still use modules. Giving things names not only makes code re-usable, but shows intent. educated_foo's code, for instance, doesn't care if the input are actually numbers, though. That's not so hard to fix because we could pull in Scalar::Util and throw a grep in there. It can get even more complicated.
But, if you don't want to use the module, don't.
Hi brian,
Thanks for the input. I think I'm gonna stick with NonOO for now. But later if a naming trend emerges for such modules, I can certainly mass-rename mine.
I like Nooo. See also Object::Import and Acme::Nooo for generic solutions to this problem, which work in at least some cases.
Since Nooo is already used by Acme::Nooo, using this name will suggest that the module "deobjectivies" the OO module, which is not the case (reimplements).
I like the idea, but I'd favor doing this implicitly rather than having to time some extra stuff, for instance, implies non-oo usage
use Number::Closest "find_closest_numbers";
While importing no subs implies oo usage
use Number::Closest;
But it'd be a bit more work if the intention is to avoid loading OO deps or vice versa.
Some more thoughts:
* This differs from Alt in that Alt is about alternate implementation, while this is about alternate interface. Also, Alt-* distributions contains module with the same name as the target, so no two alternate implementation can coexist in the same installation (but that's beside the point).
* Aside from this ::NonOO stuff, there can be various alternate interfaces. ::Simple also fits here?
* For alternate OO implementation (e.g. original module uses Moose, one might create a Moo or Mouse version), this fits quite fine with the Alt scheme, although one might also choose to still use module suffix like ::Moo and ::Mouse (or ::NoMoose?) so multiple implementation can coexist.