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 ...
$my_spiffy_object->const(FOO => 42);
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.
Anyway, thats my opinion on Spiffy, feel free to take it with a giant grain of salt.
| [reply]
[d/l]
[select] |
Maybe the fact that nobody has voted on Spiffy yet could be a warning sign?
To me, Spiffy is yet another way of being too clever for your own good. It is Ingys object framework, and it is mainly used for Spoon, which in turn is a nice thing for very small, very contained scripts and nothing else. I am wary of using modules that contain way too much magic, and if I were to build a bigger framework, I wouldn't rely on anything that requires a larger span of attention from Ingys part.
To address the problem you want to solve, why not just use the following code (which I use all the time):
package My::Class;
use base 'Class::Accessor';
__PACKAGE__->mk_accessors( qw( foo bar baz ));
sub new {
my ($package,%args) = @_;
my $self = {
# Set some defaults
foo => 'The foo',
bar => 'The bar',
baz => 'The baz',
%args
};
bless $self, $package;
$self;
};
That way, you don't have to pass in hashrefs to your constructor. | [reply]
[d/l] |
Maybe the fact that nobody has voted on Spiffy yet could be a warning sign?
It could also be a sign that the module is relatively new, and/or that people don't vote much anyway (Class::Accessor has 1 vote, for instance)
To me, Spiffy is yet another way of being too clever for your own good
I must confess I feel slightly uneasy about a module that uses Exporter, OO and source filters at the same time, but OTOH it's trying to solve a couple of fairly basic (as in "hard to solve") issues with the perl OO mechanism. Whether these issues need solving is ofcourse debateble.
If cleverness alone would be a problem, people wouldn't use Class::DBI::Loader either. It all depends on the problem you're trying to solve. If you want full control and performance, you use DBI directly. If you want to quickly write some code to edit a couple of tables in a database and performance isn't your primary concern, Class::DBI::Loader might be perfect for you.
I wouldn't use Spiffy for anything large at the moment (it looks almost impossible to remove after you've put it in your code, which can be a big problem if it doesn't work as well as you expected), but using it in a smaller project should be interesting, and might also give more insight into Spiffy's (dis)advantages. I'd welcome a couple of reviews :-)
updated: punctuation.
| [reply] |
Last I checked, the development version of YAML on CPAN also depended on Spiffy. Kinda scary.
| [reply] |
Spiffy is also used by IO::All. I have used it because I worked on IO::All::LWP, and I'm happy so far, but I really don't know enough about it to consider myself an evangelist.
| [reply] |
WOW, ingy, author of Spiffy, is using Spiffy in modules he is writing/maintaining? You don't say /sarcasm
| [reply] |