DISCLAIMER:
This post is not really evangalism. But my guess is that you are not looking for blind praise, but rather opinions. I should say that I have never used Spiffy, but I have looked at it very seriously and very closely (reading the docs, the source and the tests). I did this because I was considering using it at my work, but I decided against it, and here is why.
My single biggest problem with Spiffy is the name. Now I do think that Spoon and Spork are fun names, and since they are for applications/frameworks I have no problem with this. But Spiffy is supposed to be a swiss-army base class of sorts, and something I might use within my application. Some of our clients are pretty serious people, who would like not find it humorous that their entire application is built upon a base class called Spiffy (unless of course I could come up with some very serious sounding acryonm and convince them it stood for that).
And its not just my clients either, I am a big fan of the $long_and_descriptive_variable_name school of thought, and I actually enjoy reading code (sick, I know). So for me the naming of variables/packages/classes/etc. is very important, so much so that when the reporting application I was working on changed from yearly reports to an 18-month report cycle, I carefully searched and replaced every instance of $report_year with $report_cycle. The name Spiffy tells me nothing about what Spiffy is and does. For the next person than comes along after me its even worse.
Now all this aside, I do think Spiffy has some interesting ideas in it, but I dont think they should all be in the same place, much less in a base class. I would much more prefer to have them as seperate classes, which I can inherit from as I need to.
- The source filtering to include my $self = shift I think is not really necessary. Its just a convience, which to me is not very convient because it forces me to change the way I code.
- The inheritied exporting is a really nice idea, but I, like the OP, tend to think of OO and exporting as mutually exclusive. However, I can see where it might come in handy on occasion, but that said if I am not going to use it, I don't think I would want it cluttering up my module.
- The Mix-ins/Roles feature is an interesting solution to the problem (injecting combination classes into the heirarchy). But I wary of the complexities of a solution like this, especially where it affects things like SUPER::. The super method provided by Spiffy does seem to indicate it will handle things correctly, but there are only 2 test files for the mix-ins/roles and neither address super and the test file for super does not address mix-ins/roles. Having written Class::Trait (which is tested to work correctly with SUPER::), and having read a good deal on this particular subject, I know its a hard one to get right, and not testing it does not increase my confidence in his solution.
- I am really not a fan of the debugging functions, the names (XXX, ZZZ, YYY) are horrible (see my rant above about names).
- The built-in constructor in Spiffy is kind of cool:
Every foundation class has a constructor method to inherit, and Spiffy is no exception. Spiffy has a class method called new that creates a new object. It accepts keyword/value pairs as arguments. Each keyword is considered to be a method, and will be called on the new object using the associated value.My only problem is that, this would seem to require an accessor/mutator for each field I want initialized. I am on of those people who does not write accessors/mutators unless I really absolutely need them, I like my encapsulation. This is another reason why I would like to see this broken up a bit more, so I could use this when I wanted to , and leave it out when I dont.
- The misc. Spiffy methods/functions are nice, but nothing that can't easily be solved with something else. I don't know if I would use them all that much to be honest. I also dont like the idea that they are imported into my classes namespace, because that means they can be called through my class. It makes no sense for this to be possible ...
but it would be since const is imported into the classes namespace. For me use constant FOO => 42 is better not only because it keeps my namespace clean, but because it happens early in the compile time phase.$my_spiffy_object->const(FOO => 42);
Anyway, thats my opinion on Spiffy, feel free to take it with a giant grain of salt.
In reply to Re: Wanted: Spiffy evangelist
by stvn
in thread Wanted: Spiffy evangelist
by grantm
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |