Front page | perl.perl5.porters |
Postings from July 2010
On Thu, Jul 22, 2010 at 9:35 PM, Jesse Vincent <jesse@fsck.com> wrote: > > >> >> The only way to subclass it is a monolithic copy/paste. I don't see that it being added hurts anything existing. > > That sounds like something it would be great to fix. > I agree whole-heartily with that. By doing the magic necessary to disentangle the guts of Locale::Maketext from the original implementation idiosyncrasies (which are for example the use of simple Perl hashes and replacing its entries as they get interpreted / compiled), that would be a promising path for the evolution of the module without inadvertent effects to what already works with Locale::Maketext. Of course, that's not an easy task. I already suggested to the tickets' original requestor that forking Locale::Maketext, approaching the inability to extend it which is caused by the actual code structure, and offering such rewrite so it can prove its power / value (by benchmarks and by being applied to actual code / applications), that would gives us confidence to think about replacing the original module. Sorry for being so conservative, but I really believe that Locale::Maketext code should not grow to be more complicate (and expensive in performance and maintenance efforts) that it already is. Best, Adriano >> >> The goal was to avoid polluting the lexicon namespace with another special variable. Since each lexicon is it's own package, it made more sense to put it outside the lexicon. If that's really what's causing you to hesitate, I have no issues providing an amended patch which uses the lexicon instead to look for the _ONE_SIDED flag. > > It's certainly _one_ thing that's causing me to hesitate. I'd rather a > special key in the lexicon that works just like the other special key in > the lexicon than something similar that's different. But see above. > > Jesse >> Todd > > -- >Thread Previous | Thread Next