[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