[SearchBuilder-devel] problems with capitalization.pm and OO modules

Ruslan U. Zakirov Ruslan.Zakirov at miet.ru
Tue Jun 14 19:48:49 EDT 2005


David Glasser wrote:
> capitalization.pm is fundamentally incompatible with OO modules.
> 
> Given a class such as SearchBuilder, the lower-case methods are  aliased
> to the uppercase methods.
> 
> However, when you subclass SearchBuilder, you run into problems.   Let's
> say you want to override SomeFunction.  There are a few choices:
> 
> (a) Define SubClass::SomeFunction.  But then if you use - >some_function
> in your code anywhere, it won't find  SubClass::SomeFunction -- it'll
> call SearchBuilder::some_function,  which is aliased to
> SearchBuilder::SomeFunction.
> 
> (b) Define SubClass::some_function.  But then if you use - >SomeFunction
> in your code anywhere, or in fact wherever  SearchBuilder.pm *itself*
> uses ->SomeFunction, it won't find  SubClass::some_function -- it'll
> call SearchBuilder::SomeFunction.
> 
> (c) Require every subclass of SearchBuilder to define the methods  that
> they override as CamelCase, and to also use capitalization to 
> lower_case all functions that they override.  But in this case:
>    * capitalization is no longer the optional feature that we  advertise
> it as -- anybody who ever wants to make a subclass **must**  follow this
> rule
>    * it requires subclassers to use CamelCase, which kind of defeats 
> the point of allowing customizable casing
(d) Require every subclass put next code to the end of the package
if( eval { require capitalization } ) {
        capitalization->unimport( __PACKAGE__ );
}

> 
> For example, I wouldn't be surprised if there are bugs with using 
> lower_case method names when addressing a  SearchBuilder::Record::Cachable.
> 
> Attached is a tarball showing this problem; just run test.pl to see 
> what's going on.
> 
> Any ideas?
IRC log:
ruz     glasser: do you know that prev SB without cap.pm has bug you
described too?
glasser ruz: yup
glasser I'm not sure if transparent API renaming is a particularly
solvable problem
glasser but it's worse to have a broken implementation than none at all
ruz     so it's just broken idea to self-capitalize modules
glasser yeah
ruz     cap.pm is useful only if you want use some module with CamelCase
methods, but all your methods in lower_case, but you want one style
obra    So? do we branch for SB 2.0 and switch the API to all lower?
ruz     obra: to be more bug safe on the client side we should leave one
API. if perl world prefer lower case so it would be lower case
obra    right.


> 
> I've tried the relatively obvious thing which aliases the new_name to
>   sub { my $self = shift; $self->$CamelName(@_) }
> While this at least fixes the problem of "I overrode it with  CamelCase
> and I called it with lower_case and it didn't work", it  doesn't fix the
> opposite problem.  There might also be some  complicated ugly
> AUTOLOAD-based way to deal with this, but I'm not  sure what that would
> be.  Or perhaps you could do something involving  actually asking SB for
> one API or the other when you use it?  So you  might do
> 
>   use MySBSubclass qw/:lower_case/;
> 
> and the import function would decapitalize MySBSubclass and all of  its
> superclass' methods right then?
IMHO better leave only one API.

> 
> --dave
>   Code Monkey, Best Practical Solutions
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SearchBuilder-devel mailing list
> SearchBuilder-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/searchbuilder-devel



More information about the SearchBuilder-devel mailing list