Партнёры:
Хостинг:
Spiffy - Spiffy Perl Interface Framework For You
package Keen;
use Spiffy -Base;
field 'mirth';
const mood => ':-)';
sub happy {
if ($self->mood eq ':-(') {
$self->mirth(-1);
print "Cheer up!";
}
super;
}
Spiffy borrows ideas from other OO languages like Python, Ruby, Java and Perl 6. It also adds a few tricks of its own.
If you take a look on CPAN, there are a ton of OO related modules. When starting a new project, you need to pick the set of modules that makes most sense, and then you need to use those modules in each of your classes. Spiffy, on the other hand, has everything you'll probably need in one module, and you only need to use it once in one of your classes. If you make Spiffy.pm the base class of the basest class in your project, Spiffy will automatically pass all of its magic to all of your subclasses. You may eventually forget that you're even using it!
The most striking difference between Spiffy and other Perl object oriented base classes, is that it has the ability to export things. If you create a subclass of Spiffy, all the things that Spiffy exports will automatically be exported by your subclass, in addition to any more things that you want to export. And if someone creates a subclass of your subclass, all of those things will be exported automatically, and so on. Think of it as ``Inherited Exportation'', and it uses the familiar Exporter.pm specification syntax.
To use Spiffy or any subclass of Spiffy as a base class of your class, you specify the "-base" argument to the "use" command.
use MySpiffyBaseModule -base;
You can also use the traditional "use base 'MySpiffyBaseModule';" syntax and everything will work exactly the same. The only caveat is that Spiffy.pm must already be loaded. That's because Spiffy rewires base.pm on the fly to do all the Spiffy magics.
Spiffy has support for Ruby-like mixins with Perl6-like roles. Just like "base" you can use either of the following invocations:
use mixin 'MySpiffyBaseModule';
use MySpiffyBaseModule -mixin;
The second version will only work if the class being mixed in is a subclass of Spiffy. The first version will work in all cases, as long as Spiffy has already been loaded.
To limit the methods that get mixed in, use roles. (Hint: they work just like an Exporter list):
use MySpiffyBaseModule -mixin => qw(:basics x y !foo);
In object oriented Perl almost every subroutine is a method. Each method gets the object passed to it as its first argument. That means practically every subroutine starts with the line:
my $self = shift;
Spiffy provides a simple, optional filter mechanism to insert that line for you, resulting in cleaner code. If you figure an average method has 10 lines of code, that's 10% of your code! To turn this option on, you just use the "-Base" option instead of the "-base" option, or add the "-selfless" option. If source filtering makes you queazy, don't use the feature. I personally find it addictive in my quest for writing squeaky clean, maintainable code.
A useful feature of Spiffy is that it exports two functions: "field" and "const" that can be used to declare the attributes of your class, and automatically generate accessor methods for them. The only difference between the two functions is that "const" attributes can not be modified; thus the accessor is much faster.
One interesting aspect of OO programming is when a method calls the same method from a parent class. This is generally known as calling a super method. Perl's facility for doing this is butt ugly:
sub cleanup {
my $self = shift;
$self->scrub;
$self->SUPER::cleanup(@_);
}
Spiffy makes it, er, super easy to call super methods. You just use the "super" function. You don't need to pass it any arguments because it automatically passes them on for you. Here's the same function with Spiffy:
sub cleanup {
$self->scrub;
super;
}
Spiffy has a special method for parsing arguments called "parse_arguments", that it also uses for parsing its own arguments. You declare which arguments are boolean (singletons) and which ones are paired, with two special methods called "boolean_arguments" and "paired_arguments". Parse arguments pulls out the booleans and pairs and returns them in an anonymous hash, followed by a list of the unmatched arguments.
Finally, Spiffy can export a few debugging functions "WWW", "XXX", "YYY" and "ZZZ". Each of them produces a YAML dump of its arguments. WWW warns the output, XXX dies with the output, YYY prints the output, and ZZZ confesses the output. If YAML doesn't suit your needs, you can switch all the dumps to Data::Dumper format with the "-dumper" option.
Spiffy considers all the arguments that don't begin with a dash to comprise the export specification.
package Vehicle;
use Spiffy -base;
our $SERIAL_NUMBER = 0;
our @EXPORT = qw($SERIAL_NUMBER);
our @EXPORT_BASE = qw(tire horn);
package Bicycle;
use Vehicle -base, '!field';
$self->inflate(tire);
In this case, "Bicycle-"isa('Vehicle')> and also all the things that "Vehicle" and "Spiffy" export, will go into "Bicycle", except "field".
Exporting can be very helpful when you've designed a system with hundreds of classes, and you want them all to have access to some functions or constants or variables. Just export them in your main base class and every subclass will get the functions they need.
You can do almost everything that Exporter does because Spiffy delegates the job to Exporter (after adding some Spiffy magic). Spiffy offers a @EXPORT_BASE variable which is like @EXPORT, but only for usages that use "-base".
Mixins can be thought of at a simplistic level as importing the methods of another class into your subclass. But from an implementation standpoint that's not the best way to do it. Spiffy does what Ruby does. It creates an empty anonymous class, imports everything into that class, and then chains the new class into your SI ISA path. In other words, if you say:
package A;
use B -base;
use C -mixin;
use D -mixin;
You end up with a single inheritance chain of classes like this:
A << A-D << A-C << B;
"A-D" and "A-C" are the actual package names of the generated classes. The nice thing about this style is that mixing in C doesn't clobber any methods in A, and D doesn't conflict with A or C either. If you mixed in a method in C that was also in A, you can still get to it by using "super".
When Spiffy mixes in C, it pulls in all the methods in C that do not begin with an underscore. Actually it goes farther than that. If C is a subclass it will pull in every method that C "can" do through inheritance. This is very powerful, maybe too powerful.
To limit what you mixin, Spiffy borrows the concept of Roles from Perl6. The term role is used more loosely in Spiffy though. It's much like an import list that the Exporter module uses, and you can use groups (tags) and negation. If the first element of your list uses negation, Spiffy will start with all the methods that your mixin class can do.
use E -mixin => qw(:tools walk !run !:sharp_tools);
In this example, "walk" and "run" are methods that E can do, and "tools" and "sharp_tools" are roles of class E. How does class E define these roles? It very simply defines methods called "_role_tools" and "_role_sharp_tools" which return lists of more methods. (And possibly other roles!) The neat thing here is that since roles are just methods, they too can be inherited. Take that Perl6!
my $self = shift;
This statement is added to every subroutine in your class by using a source filter. The magic is simple and fast, so there is litte performance penalty for creating clean code on par with Ruby and Python.
package Example;
use Spiffy -Base;
sub crazy {
$self->nuts;
}
sub wacky { }
sub new() {
bless [], shift;
}
is exactly the same as:
package Example;
use Spiffy -base;
use strict;use warnings;
sub crazy {my $self = shift;
$self->nuts;
}
sub wacky {my $self = shift; }
sub new {
bless [], shift;
}
;1;
Note that the empty parens after the subroutine "new" keep it from having a $self added. Also note that the extra code is added to existing lines to ensure that line numbers are not altered.
"-Base" also turns on the strict and warnings pragmas, and adds that annoying '1;' line to your module.
package Keen;
use SomethingSpiffy -Base;
# normal public method
sub swell {
$self->$stinky;
}
# private lexical method. uncallable from outside this file.
my sub stinky {
...
}
my @stuff = grep { /keen/ } $self->find($a, $b);
If you have a problem with this statement, you can debug it in any of the following ways:
XXX my @stuff = grep { /keen/ } $self->find($a, $b);
my @stuff = XXX grep { /keen/ } $self->find($a, $b);
my @stuff = grep { /keen/ } XXX $self->find($a, $b);
my @stuff = grep { /keen/ } $self->find(XXX $a, $b);
XXX is easy to insert and remove. It is also a tradition to mark uncertain areas of code with XXX. This will make the debugging dumpers easy to spot if you forget to take them out.
WWW and YYY are nice because they dump their arguments and then return the arguments. This way you can insert them into many places and still have the code run as before. Use ZZZ when you need to die with both a YAML dump and a full stack trace.
The debugging functions are exported by default if you use the "-base" option, but only if you have previously used the "-XXX" option. To export all 4 functions use the export tag:
use SomeSpiffyModule ':XXX';
To force the debugging functions to use Data::Dumper instead of YAML:
use SomeSpiffyModule -dumper;
package Example;
use Spiffy -Base;
field 'foo';
field bar => [];
sub lalala {
$self->foo(42);
push @{$self->{bar}}, $self->foo;
}
The first parameter passed to "field" is the name of the attribute being defined. Accessors can be given an optional default value. This value will be returned if no value for the field has been set in the object.
const bar => 42;
The "const" function is similar to <field> except that it is immutable. It also does not store data in the object. You probably always want to give a "const" a default value, otherwise the generated method will be somewhat useless.
stub 'cigar';
The "stub" function generates a method that will die with an appropriate message. The idea is that subclasses must implement these methods so that the stub methods don't get called.
sub foo {
super; # Same as $self->SUPER::foo(@_);
super('hello'); # Same as $self->SUPER::foo('hello');
$self->bar(42);
}
sub new() {
my $self = super;
$self->init;
return $self;
}
"super" will simply do nothing if there is no super method. Finally, "super" does the right thing in AUTOLOAD subroutines.
$self->mixin('SomeClass');
$object->mixin('SomeOtherClass' => 'some_method');
sub boolean_arguments { qw(-has_spots -is_yummy) }
sub paired_arguments { qw(-name -size) }
my ($pairs, @others) = $self->parse_arguments(
'red', 'white',
-name => 'Ingy',
-has_spots =>
-size => 'large',
'black',
-is_yummy => 0,
);
After this call, $pairs will contain:
{
-name => 'Ingy',
-has_spots => 1,
-size => 'large',
-is_yummy => 0,
}
and @others will contain 'red', 'white', and 'black'.
Any non-paired parameters act like a normal import list; just like those used with the Exporter module.
package Something;
use Spiffy::Module -base;
use base 'NonSpiffy::Module';
Now it may be hard to keep track of what's Spiffy and what is not. Therefore Spiffy has actually been made to work with base.pm. You can say:
package Something;
use base 'Spiffy::Module';
use base 'NonSpiffy::Module';
"use base" is also very useful when your class is not an actual module (a separate file) but just a package in some file that has already been loaded. "base" will work whether the class is a module or not, while the "-base" syntax cannot work that way, since "use" always tries to load a module.
There are two caveats.
If you get this error, simply put a statement like this up front in your code:
use Spiffy ();
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
See <http://www.perl.com/perl/misc/Artistic.html>
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |