Recently I've been reading TheDamian's wonderful book: "Object Oriented Perl" and it got me thinking about the following standard usage of Class::DBI. The meditation is probably neither here nor there.

To create a simple class Foo derived from Class::DBI, one can do something like: 

package Foo;
use strict;
use Class::DBI;
use base 'Class::DBI';

Foo->set_db('Main',"url","user","password");
Foo->table('Foo');
Foo->columns(All=>qw/id name/);

sub method1{}
sub method2{}

[download]
Now to get an instance of the Foo class, I can simply call the retrieve() method implemented in the base class(i.e.,Class::DBI), and call any method on the derived class(i.e., Foo): 
my $foo = Foo->retrieve(1); # for row with id 1.
$foo->method1();

[download]
This is all wonderful and natural, for perl. But I realized I can't do that easily in a static language, say Java: if retrieve() is defined/implemented in the base class, its return type has to be the base class, so unless one explicitly cast the returned object to the derived class, one can't call any method of the derived class. In fact, one can look at a general persistent framework like Hibernate, the query/finder method always requires casting ( the save() method is ok since it returns void.) One can further look at EJB, where the finder method is always part of a bean's home interface, there can't be a general finder method (unless some casting is involved). I always feel it's bad design if one has to do much casting. This seems to be at least one advantage of OO for dynamic languages: there is no static type to restrict what method you can call, so you can have at least a general finder method.

Replies are listed 'Best First'.
Re: perl, Class::DBI and OO for dynamic languages
by dragonchild (Archbishop) on Dec 15, 2004 at 13:24 UTC
    That's not an OO issue - it's the fact that Perl doesn't have return types. In Java and C++, you have to declare the return type for a given function. Perl doesn't do that, so it can return whatever it wants. (q.v. wantarray for more fun and games.)

    Now, many OO purists would say that you shouldn't be doing things like that. Instead, I would suppose they'd argue you should do something more like this: 

    Foo foo = new Foo;
foo->retrieve( 1 );
foo->method1();

    [download]
    That would be Java or C++ syntax. (It's kinda scary how similar they look ...) All the methods would have a void return type, meaning that the object stayed encapsulated.

    *shrugs* Reason #237908 I choose to program in Perl, I guess ...

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[d/l]
      I disagree. Home classes (in EJB) deal with record management. Finding, creation and deletion of stuff. Your actual record, your object handles business like logic, i.e. in the case of a bank account, withdrawls, interest, computations. It also deals with getting and setting data. Persistence is handled transparently. It keeps the actual db portions very seperate from everything else.

      Your particular example, I've done in perl btw :)

      ----
      Give me strength for today.. I will not talk it away..
      Just for a moment.. It will burn through the clouds.. and shine down on me.

[reply]
Re: perl, Class::DBI and OO for dynamic languages
by Anonymous Monk on Dec 15, 2004 at 15:02 UTC
    "I always feel it's bad design if one has to do much casting."

    Totally. It's also an argument for well defined interfaces in static languages, so in this case, it's best to code in your static languages in ways that the type of the object is not important to you -- i.e. base classes and interfaces.

    of course I like duck typing much more...

[reply]
Re: perl, Class::DBI and OO for dynamic languages
by exussum0 (Vicar) on Dec 15, 2004 at 17:10 UTC
    On ejb, you need to cast for returning Collections, because they contain Objects. EJB requires you to either return Collections or a single row represented by an object. If you do the latter, no casting is involved. In the prior, you have to because they are collections of Objects.

    ----
    Give me strength for today.. I will not talk it away..
    Just for a moment.. It will burn through the clouds.. and shine down on me.

[reply]
Re: perl, Class::DBI and OO for dynamic languages
by Anonymous Monk on Dec 15, 2004 at 16:54 UTC
    I always feel it's bad design if one has to do much casting.
    Hate to break it to you buddy, but just because you can't see perl doing 'casting' doesn't mean it's not happening all over the place. Perl's weak typing allows variable to transform between numbers, strings, and object almost transparently. That is part of DWIMmery. The difference between perl and a static language like java is that you have to explicitly tell java what you mean instead of it guessing. One is implicit casting one is explicit casting.
[reply]

      Perl's object system is completely seperated from its type system.

      I really don't want to start another thread on this, so I'll just point everyone to the recent discussion on strong typeing in Perl.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]

Back to Meditations