in reply to A Growing Dislike for SQL-OOP Mappers

I don't see much here that is specific to O/R mappers. What you seem to be saying is that when subclassing things you have to be careful not to conflict with methods in the base class. That's true of anything. If I subclass CGI.pm and want to add a method called param() to my class, it will conflict.

As for add_to_*, well, you have to commit to some API sometime. I'm not really sure what you are complaining about there. When I don't like the Class::DBI methods, I make my own. If I stop using Class::DBI, I can implement whatever public methods I created using vanilla DBI or Rose::DB or whatever else I happen to switch to.

  • Comment on Re: A Growing Dislike for SQL-OOP Mappers

Replies are listed 'Best First'.
Re^2: A Growing Dislike for SQL-OOP Mappers
by jk2addict (Chaplain) on Aug 22, 2005 at 18:24 UTC
    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.

[reply]
      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.

[reply]
[d/l]
[select]
        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.

[reply]

In Section Meditations