Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

barbie (2653)

  reversethis-{ku. ... m} {ta} {eibrab}

Leader of [] and a CPAN author []. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [] and the QA Hackathon [] websites. Also the current caretaker for the CPAN Testers websites and data stores.

If you really want to find out more, buy me a Guinness ;)

Memoirs of a Roadie []
CPAN Testers Reports []
YAPC Conference Surveys []
QA Hackathon []

Journal of barbie (2653)

Saturday December 06, 2003
04:07 AM

More Class::Phrasebook

[ #16188 ]
A while ago I got in touch with Rani Pinchuk regarding his module Class::Phrasebook. Seeing as the project I was working on was not going to install an external binary XML Parser, I had to look for an alternative. I came up with an INI configuration file implementation, using Config::IniFiles to extract the phrases. Having posted in my journal, it was suggested that I contact Rani and see what he thought. So I did.

After a few emails flying back and forth regarding ideas for improvements, expanding the usage, etc. it all went quiet for a while. We both had other things to work on, so didn't have the time to take it further at that point. But we did say we'd both have a think and see where it takes us.

Rani got in touch this week, and has started a sourceforge project for Class::Phrasebook. However he had some doubts about changing the module.

Most people who have contacted him have praised his module and are using it very nicely, which is great, as it IS a nice module and it's always nice to know people are using and appreciating your work. However, he's only had a few emails asking about other forms of a datastore. Someone asked for another XML format, another asked about a database implementation (which I like the sound of) and my INI configuration file implementation. As most people seem to be using the module rather well, he's dubious of the effort to extract the datastore code, debug code, error code, etc into separate modules and simplify the interface so that it can be expanded for future datastores. I have to say I'm a bit disappointed, but then that's his choice.

If I'd have received these email it would have spurred me on to try facilitate the ideas. As most people don't contact you about a module, whether good or bad. So if I received more than one mail about extending a module, it would imply to me there are several others out there who might benefit from the choice on offer.

If Rani is reluctant to change the current implementation, I may well try it myself and see if I can create a working version of the current XML based phrasebook, alongside a couple of others. Then send the whole lot to Rani and see what he thinks. To a degree I can understand why he doesn't want to change it, as why fix something that isn't broken for you. However, I do think the idea of a Class::Phrasebook is bigger than one implementation. Plus surely, Class implies sub-classing, inheritence and other such OO things. None of which Class::Phrasebook does.

I've sent him a reply to try and convince him it something worth doing, so we'll see where it takes us.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • this [] of any use to you?
      ---ict / Spoon
  • I haven't checked, but would it be possible to just subclass Class::Phrasebook and release the subclass onto CPAN? Or is it not well structured enough to do that?

    I seem to recall a rant on use.perl recently about CPAN people not making enough use of subclassing...


    • This is exactly what I would like Class::Phrasebook to be able to do. Then having different datastores or different renderings would be as easy as plugging it all together. However, currently the module is a single entity and heavily reliant on an XML parser.

      With the code from koschei and my code and ideas, I should be able to put forward a case for a change. We'll see :)