Very neat! I do like the elegance of the small size, and
looking at your other modules and this one, you have good
ideas and are capable of implementing them. I do have to agree
that a lot more people would have a lot more fun with this
module if you *cough* documented it. The chorus here is usually
that a few implementations are okey - people will pick the
best one - and a module that is smaller, simplified, specialized,
better maintained, or has some other advantage - offers a useful
alternative. Usually there is only griping when a large number
of people suddenly think it would be spiffy to do their own
version of X, and this has certainly happened a few times.
I think you've just gotten on peoples bad side for the lack
of POD. If you search Google, there are a few very quick,
very simple quick references, and what h2xs spits out is
adequate to learn enough to fake it enough to be useful. I'm
not sure I like where this flogging people in public thing
is going on cpanratings.perl.org, so I've gone through and
given all of my modules bad reviews. Bwahaha! Buck the system!
Hope this helps! -scott
Perl doesn't need design patterns. Design patterns are just
repeated sequences of code to work around failings of OO
systems. Most perl programmers don't even use OO to avoid
these problems. OO is over rated. If this is about design
patterns, it must be about OO, and OO is overkill. Packages
are all that is needed to write modular code. Java programmers
only use objects because the class libraries make them and there
are no other shortcuts in the language anyway. Patterns are
dumb. And design is completely pointless too. Perl programs
never get large enough that design is a problem. People
never put together teams of Perl programmers and one person
doesn't need to design their own code. Programs grow
organically. They go from small to big, cute to gnarly,
simple to twisted. When they get big and old, they die. No one
works on old code and no one uses old code. If programs expired
like eggs, people wouldn't even talk about nonesense like
software design and computer science. Those Java people must
take us Perl programers as real dunderheads to think we'd
bite on something as lame as this. -scott
Too many usage idioms, none of them simple and clean enough.
symbol table entries are stolen from the package and moved into
another is particuarly disturbing. This is going to create lots
of very hard to track bugs and just serve to confuse. This sort
of thing has been done before in various forms and serves
only to educate. It is not something that belongs on CPAN.
People will not change how they do objects in Perl so long
as the default is the default. People should give up trying
to reimplement something that is already reimplemented and
people are happy with. This is just another implementation
of a tired idea. -scott
Ignorantly implemented and naively conceived, this code should
never have been shown to anyone, not even for feedback.
The documentation is full of spelling and grammar errors.
Using subclasses to control permutation combined with
autoloaded operators is a confusing idiom that hasn't
proven to be particularly powerful. Something is still
missing from commercial fuzzy modeling systems that I can't
put my finger on besides just the modeling side.
Perhaps making this into a module was a bit hasty.
Sorry, folks. It isn't large and/or full featured and
other things already exist that modestly declined to use the
name. Also, interfaces don't declare themselves - modules
declare that they use an interface - with the "use interface"
construct. This is backwards. The POD suggests some other
modules to use instead. See that. Thanks. -scott