NAME
Decision::ParseTree - Replacing waterfall IF-ELSIF-ELSE blocks
VERSION
Version 0.01
SYNOPSIS
Death to long if-elsif-else blocks that are hard to maintain, and hard to explain to your manager. Heres an overly simplistic example:
OLD CODE
if ( $obj->is_numeric ) {
if ( $obj->is_positve ) {
print 'Positive Number';
}
elsif ( $obj->is_negative )
print 'Negative Number';
}
else {
print 'Looks like zero';
}
else {
print 'Non-Numeric Value';
}
NEW CODE
YAML Decision Tree
---
- is_num :
0 : Non-Numeric Value
1 : - is_pos :
1 : Positive Number
- is_neg :
= : Looks like zero
1 : Negative Number
...
Rules Object
package Rules;
use Scalar::Util;
sub is_num {
my ( $self, $obj ) = @_;
return (Scalar::Util::looks_like_number($obj->{value})) ? 1 : 0;
}
sub is_pos {
my ( $self, $obj ) = @_;
return ($obj->{value} > 0 ) ? 1 : 0;
}
sub is_neg {
my ( $self, $obj ) = @_;
return ($obj->{value} < 0 ) ? 1 : 0;
}
Object to be passed
package Number;
sub new {
my ( $class, $value ) = @_
my $self = { parse_path => [],
value => $value };
return bless $self, $class;
}
DESCRIPTION
YAML as a Decision tree
To make this all work we need a few parts:
A rules object: This will be a library of rules.
An object that will be passed thru the rules.
A YAML doc that outlines your decision tree.
Why YAML
So this all started as a way to make a decision tree thats easy to parse and easy to read for non-programmers. So to do this I looked to YAML, it's easy to read and easy to parse. Though make this work we have some hard and fast rules to follow for the tree construction:
RULES are a key value pair
the key is the method to run in the rules object
the value must be an arrayref or hashref
ARRAYS are a series of rules run in order
HASHES are a series of answers
SCALARS are endpoints
Why add more parts, why blow everything in to separate objects.
Sometimes you have to make things messy before they can get clean.
Theres a flexibility that comes with breaking things apart in to nice, neat little chunks. By separating the rule logic in to one place you can make very complex rules that do not gunk up your code. You pull the order of these rules in to another place as it's completely possible that you would want to tweak the order. And lastly you need to glue these separate things together, so you have an object that gets passed thru to make this all work. Tada!
Examples
It would be nice to whip up a big example here to show all the interesting bits, sadly I can't think of a good example. Ideas?
FEATURES
tracking for free
if you have $obj->{parse_path} then every step that this obj takes thru the rules then every rule name and returned value are stored as an array of hashes
if you have $obj->{parse_answer} then the result will also be stored here as well as being returned from ParseTree.
EXPORT
ParseTree is the only thing that gets exported, it's also the only thing here.
FUNCTIONS
ParseTree($tree, $rules, $obj)
Runs $obj thru $tree, using $rules as the library of rules.
Returns the first endpoint that you run into as the answer.
CAVEATS / TODO
Currently $tree is expected to be a pre-parsed YAML File, This should change here soon to also accept a filename. Currently though it does not.
no mention of the tracking and storeing bits.
need better examples.
need to flush out the docs more.
AUTHOR
ben hengst, <notbenh at cpan.org>
BUGS
Please report any bugs or feature requests to bug-decision-parsetree at rt.cpan.org
, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Decision-ParseTree. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.
SUPPORT
You can find documentation for this module with the perldoc command.
perldoc Decision::ParseTree
You can also look for information at:
AnnoCPAN: Annotated CPAN documentation
CPAN Ratings
RT: CPAN's request tracker
Search CPAN
ACKNOWLEDGEMENTS
COPYRIGHT & LICENSE
Copyright 2007 ben hengst, all rights reserved.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.