Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^2: A Growing Dislike for SQL-OOP Mappers

by jk2addict (Chaplain)
on Aug 22, 2005 at 18:24 UTC ( #485748=note: print w/ replies, xml ) Need Help??


in reply to Re: A Growing Dislike for SQL-OOP Mappers
in thread A Growing Dislike for SQL-OOP Mappers

When I don't like the Class::DBI methods, I make my own.

My complaint was that sometimes that's just not possible if the SUPER classes internals call the method you are overriding (as apposed to it's version of that method). I only want the consumer of my class to call my new; not the the internals of the superclass; yet I still want all of the is-a relationship perks; column and setup accessors.

Updated...

For example, create a class that is-a Class::DBI and override create. Now call find_or_create(). Bad things happen.


Comment on Re^2: A Growing Dislike for SQL-OOP Mappers
Re^3: A Growing Dislike for SQL-OOP Mappers
by itub (Priest) on Aug 22, 2005 at 20:39 UTC
    The problem has nothing to do with SQL-OOP mapping; it's just general OOP. In the end, if you override create and another Class::DBI method (such as find_or_create) calls $self->create, it is perfectly natural that it will call your overriden method. That's what polymorphism is all about.

    Think about it the other way: if it worked the way you want, someone would soon complain that they overrode create and called find_or_create expecting it to call their overriden create, but it didn't.

    If you create an infinite loop or somesuch thing by overriding create, you should reconsider your strategy. You can either override find_or_create as well, or hack your method to keep state so that it breaks out of the loop.

      If you create an infinite loop or somesuch thing by overriding create, you should reconsider your strategy

      I agree. So, who needs create. It's a silly name. The same could be said about new....so in the same type of situation, I can't override new in the subclass? That's wrong IMHO. There should never be a situation where I can't provide my own new(). And I don't really think and SUPER class methods calling new on itself or it's subclass is quite kosher either; but it happens.

        I never said "don't override it", I even proposed two ways you could do it! This is a general situation: if you want to override method A so that it calls method B, and you know that method B will call method A, you can fix the loop by overriding method B. For example,
        package MyApp::DBI; use base 'Class::DBI'; __PACKAGE__->connection(...); 1; package MyApp::Gallery; use base 'MyApp::DBI'; __PACKAGE__->table('galleries'); __PACKAGE__->columns(...); sub create { my ($self, $ops) = @_; my $dir = $ops->{'directory'}; if (-e $dir) { die 'directory exists'; else { mkdir $directory; $self->find_or_create($data); }; return; }; sub find_or_create { my $class = shift; my $hash = ref $_[0] eq "HASH" ? shift: {@_}; my ($exists) = $class->search($hash); return defined($exists) ? $exists $class->SUPER::create($hash) +; } 1;
        There's nothing special about new() in Perl -- it's the same as any other method. You can override it, and you will have the same trials and tribulations with overriding it that you would have with any other inheritance scenario. It still sounds like you're complaining that you don't like OOP to me.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://485748]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2014-12-27 07:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls