in reply to perl, Class::DBI and OO for dynamic languages

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();
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.

Replies are listed 'Best First'.
Re^2: perl, Class::DBI and OO for dynamic languages
by exussum0 (Vicar) on Dec 15, 2004 at 17:15 UTC
    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.