Is Perl Truly an Object Oriented Language?

[awohld]

I was reading in some forums a couple of days ago about Object Oriented Databases where some people were saying that Perl isn't a truly Object Oriented language and thus can't interface well with OO databases. Being new to OO concepts I have no idea.

Does their assertion hold any water?

1) Is Perl a truly OO language?

2) Can it be interfaced with OO Databases easily?

[Corion]

After having ranted about this in the CB and edan prompting me to make my ranting eternal by means of a post, I call rubbish on the three questions you actually meant to pose:

1. What is an Object Oriented Database?
2. What is Truly Object Oriented?
3. How do the two things relate?

I think that these three questions have no good answers because they are all three very ill defined, at least without further context.

For example, Smalltalk people call other languages "not Truly Object Oriented", if there are things in Other Languages that are not objects, i.e. you can't call methods ("send messages" in Smalltalk-lingo) to them. In that sense, Perl is not Truly Object Oriented, as you can't call a method on an integer. autobox is a hammer to solve this perceived problem. You also can't manipulate classes as if they were objects, which has a "solution" in the form of, for example, Class::Classless. I'm not convinced that these perceived problems are actual problems, but if you're talking to somebody in the Smalltalk camp, they will use that as a line of demarcation between Truly Object Oriented and Providing Syntactical Candy to Seem Object Oriented.

There also is no standard to what databases need to provide to call themselves "Object Oriented". Any database can be called Object Oriented, as long as you restrict what you call your objects to databases, tables, rows and indices. It is an ill-defined and much abused term like "XML databases". Perl has Class::DBI which provides a thin persistence layer for objects into databases, and these two discussions pointed out to me by Super Search go much deeper into the problems and solutions of OODBMS. I don't see much use in these, because if you're going to store arbitrary objects in your database, you have a much larger problem as to what to do with these objects, and if you don't know about your objects, all you will be able to do with them is call a given set of methods on them, operating on them in an iterative fashion, instead of operating on them as a set, like traditional RDBMS do. Then, you are likely either well off using a tied hash to serialize your object data, or using Class::DBI, depending on whether you want to go the extra mile to define a database schema for your objects or just serialize them as blobs.

As I didn't come up with a favourable answer to any of the first two questions, the third won't be answered by me either, at least not in a constructive way - you can always map an "object" to a "data structure" and code that operates on it, like, say, a hash, and a set of functions that all take the hash as the first parameter. So there is not much sense in saying that only a Truly Object Oriented Language can interoperate with an Object Oriented DB. Perl also has enough of introspection and the eval statement so that you can generate classes on the fly, so as long as the database lets you in on the object format, you can create a suitable class for it. Whether that is what was meant, I don't know though.

[talexb]

Thank you for your wonderfully spirited response.

I plan to print this out and keep it with me the next time I'm talking with someone and they tilt their head, furrow their brow and say, "But is it truly OO?", at which point I will smile broadly and leap into a fascinating but mostly pointless discussion of What OO Means Anyway.

I won't end up working there (yes, I admit, I did picture an HR droid with their Arts degree on the wall), but I'll know I had the Right Answer To An Ugly Question.

[dimar]

Wait a minute ... are you saying someone asked you these very same questions in a *job interview*??

[nothingmuch]

You also can't manipulate classes as if they were objects

Well, in perl someone could write a Class::AsObject module which injects methods like delete_symbol, create_subclass($name), add_field, add_method, and so forth into the UNIVERSAL namespace. These methods simply work as class methods, with the instance data sort of being the symbol table hash that the class takes up.

$r = Dog->create_subclass("Rottweiler"); # eq Dog::Rottweiler
$r->add_method(bark => sub { print "roar" });

*shudder*

[gaal]

I have this marketing detector. The word "truly" trips it every time.

Perl's OO syntax was addeded rather later than most of its other features. Sometims this shows. There's a loose default recommendation for how to "do" OO in Perl, but it's certainly not indisputable and some people indeed write OO Perl and avoid the regular object system. As always with Perl, there's more than one way to do it, and that doesn't mean you can't do it.

Tell us what you want to do more specifically.

[Cap'n Steve]

Well, I'm no expert, but when I see "Object Oriented Language" I think of (please don't down vote me for using this ;)) Visual Basic.

[Anonymous Monk]

I guess this was a joke (sorry if not), but you should think "Ruby" or "Smalltalk". C++ and Java have some OO in them, but are not pure.

[gellyfish]

1. Perl can support OO Programming, but it can also support procedural programming so it isn't a pure OO language (whatever that means.)
2. Depends what you mean by OO Databases - it can certainly interface (via the DBI) to databases that support an OO model

/J\

[herveus]

Howdy!

...of course, Java is equally impure as an OO language...

[Arrowhead]

I'll stick to question number 2:

Take a look at http://search.cpan.org/~seyn/Pogo-0.10/Pogo.pm and decide for yourself. The OO database used is called GOODS, more information about it and several other OO databases for different programming languages can be found at http://www.garret.ru/~knizhnik/.

[herveus]

Howdy!

...well, their assertion holds a bit of water, I suppose. After all, even a sieve holds a bit of water.

What is meant by "a truly OO language"? Perl does OO stuff, some of it quite well, other parts with some difficulty. What languages are "truly OO"?

If there is an API, one can probably put a Perl face on it. On the other hand, unless the database supports SQL, or something sufficiently isomorphic, DBI will probably not be as helpful as one might like.

[gothic_mallard]

A "true" object orientated language tends to be defined as one in which everything is an object from integers to operators and upwards.

Lanuages such as Ruby purport to be as such although I don't believe even that is 100% OO from what I've read (although I wouldn't quote me on that :))

[Joost]

AFAIK (I've been doing some reading on Ruby last couple of weeks) in Ruby everything (well, everything you can store or pass around; classes, literal strings, numbers, symbols, code blocks etc. etc.) really is an object.

100% OO is something else, though. You still have some operators that aren't method calls, but not many; iterators like each and math ops like + and <=> etc. are just method calls in Ruby.

[Jenda]

Ad 1) The question is, who cares???

Ad 2) Yes. Perl is generaly great at interfacing with anything. Just because it's not what would the purists call "truly OO language". Just because it doesn't force everything to be an object no matter how badly does it fit.

[hardburn]

The question is, who cares???

Have you looked at Ruby? I wasn't convinced that totally-pure OO was useful until I saw Ruby.

That isn't to say that every language needs to be purely OO. Just that some languages are and manage to get some really cool and useful features because of it. Certainly, you don't need it to interface with OO databases.

Further, if someone is preaching the benefits of a "pure-OO" language, they better not be using (by choice) Java or C++.

[tall_man]

This reminds me of the paper by Stroustrup about C++, "Why C++ is not just an Object-Oriented Language" found here.

Like C++, Perl is a multi-paradigm language. It can support structured, object-oriented, and functional styles. It is not "pure object-oriented", but people who want that seem to use "object-oriented" as a synonym for "good."

The second question is rather vague. What "OO Databases" do they mean? The concept seems to be that sets of Java objects (or C++ objects, etc.) can be saved to the file system and then retrieved later. The format is almost always language-specific and vendor-specific. Sometimes object-relational mapping is used behind the scenes, sometimes not.

If this is what they mean, it might be difficult for Perl (or any other language other than the target language of the ODBMS) to make use of the data. Perl would have to call wrappers to the target language. It might be a bit easier to do so for C++ than Java, since Perl has a C base.

[yacoubean]

I took quite a number of database classes in school, and they all dealt with relational databases. However, we covered OO databases, and from what I remember they are completely different from relational. For example,

select * from emps a, payroll b
where a.empid = b.empid

would not work in an OO database, because this is using relational logic. I might be wrong here, because I've never worked with an OO database.
Also, we talked about the fact that OO databases are still very obscure, and in the opinion of my professors, there is a good reason they are. The idea behind them pretty much sucks. Somethimes I think people go a little overboard with the beauty of OO abstraction. Yes its cool, but there are lots of cases where OO is too much work and/or it's inefficient. That's why Perl is such a popular language, because its designer recognized that most people hate being constrained to a difficult and obtuse function, especially when it's inefficient.

[aerts]

To clarify the aspects of both types of databases a bit: I'm using an OO database at work stuffed with genomics data based on the AceDB database. The problem with object-oriented databases is that they (at least not AceDB) don't support relationships except when defined in the objects themselves. Let me explain: suppose you want to store the names of villages and the persons living in those villages:
• in a relational database, you would create 2 tables: 'villages' and 'persons'. A truly relational way to create links between the two, would be to create a third table 'villages2persons', which holds only 2 columns: one with the IDs from villages and one with the IDs from persons.
• in a OO database, there are objects from the class 'village' and objects from the class 'person'. The problem starts when making links: within every village object, a list of IDs from persons has to be kept AND in every person object, a village ID should be added. (Of course, there are workarounds, but then you're distracting from the OO setup of the database) Ergo: same information is stored twice. Ergo again: _very_ high change to create inconsistencies when updating data and stuff.

[Corion]

Of course, you could solve this problem in the same way you solve it with a relational database, by introducing the Residency object (you called it villages2persons), and then navigating Village->Residency->Person to get at the persons of a village, but that way, you've just replicated the relational model onto the object database - which most likely isn't what was intended.

[exussum0]

From what I understand, which may be wrong as always ;), is..

sql: select book.* from author, book where author.id=book.authorid_id and author.name='bob'

oo-sql: select author.books from author where author.name = 'bob'

[Anonymous Monk]

In addition to what the others asked, Which perl? perl 1-4 certainly had nothing to do with objects at all

[gellyfish]

Of course if one were to really be bothered to it would have been possible to have written in an OO-like style, it's just the language offered no support for it. Much as the same as you could do with C before the advent of C++

/J\

[Anonymous Monk]

1) Is Perl a truly OO language?

No. Perl is *not* an object oriented language. Period. Perl does have mechanisms supporting OO programming, and you can write OO applications using Perl that are "truly" OO (as if anyone could agree on either "truly" or "OO" in the first place).

2) Can it be interfaced with OO Databases easily?

Yes. There are modules performing object/relational mappings and for using object oriented databases (Class::DBI and AcePerl for example).

[William G. Davis]

I can't comment on 2), but as for 1) I would say no, definitely not.

When most people question the OO-ness of a supposedly OO language, usually it's because everything in the language is not an object. Alan Kay invented the term object-oriented to describe his language, Smalltalk, where everything is an object and all operations involve sending messages to objects.

Perl certainly doesn't fit Kay's definition, but even we use the more welcoming standard of the inheritince/encapsulation/polymorphism trio, I still think it doesn't pass, because Perl has no real object inheritance. Yes, you can inherit the methods from another class, but not objects. This results in cruft like this:

sub new {
    ...
    my $self = $class->SUPER::new;

    $self->{host} = shift;
    $self->{port} = shift;
    ...
}

which clearly violates the law of encapsulation--as well as the law of abstraction--because you have to know the internals of the class you wish to inherit from, and then you go right on in and mess with it directly.

[Anonymous Monk]

I don't see how or why, unless ofc when you implement it wrong...

First of all I don't really see a reason to call SUPER::new unless you are passing specific arguments which you should have specified (or unless there is initialisation which would better be done in a sub called initialise (or something like that)).

Second, usually you pass arguments to the constructor as a hash reference, since this makes it easier to use and a lot easier to modify (since you don't need to know/care what arguments comes first).

Third, if you need to know the internals of the class you are inheriting from then the implementation of that class isn't that good. If it would have been designed properly then it would have methods like set_host and/or set_port. (either normal methods or via the AUTOLOAD sub)

[William G. Davis]

You missed the point. "host" and "port" aren't the base class' data members, they're our data members. We created an object of the class we're inheriting from, then we went and messed with its internals by adding our own data members to it. See the problem?

Here's an example (from WWW::Mechanize):

my $self = $class->SUPER::new( %default_parms, @_ );

$self->{page_stack} = [];
$self->{quiet} = 0;
$self->env_proxy();
push( @{$self->requests_redirectable}, 'POST' );

return bless $self, $class;

[hardburn]

At some point, an inherited class has to know a little more about the internals of its parent than other code. This goes for any language, not just Perl. Not necessarily all the details, just more than normal.

Further, I never consider data in the object's underlieing reference to be private. Rather, it's more analagous to Java's protected variables, which are explicitly allowed to be fiddled with by classes in the same namespace and/or subclasses. Java enforces this, though obviously Perl doesn't (without doing a lot of extra work, anyway).

If the parent wants a truely private variable, it should have done:

package Foo;
my ($host, $port); # Private vars

# rest of class

Lexically scoped variables are very hard to get at outside the given lexical scope. At least as hard as a private var in Java.

[William G. Davis]

At some point, an inherited class has to know a little more about the internals of its parent than other code. This goes for any language, not just Perl. Not necessarily all the details, just more than normal.

Not in Smalltalk. You inherit from classes all the time without knowing their internals; only what messages they respond to. In fact, *every* object inherits--at some point--from "Object", the root of the inheritance hierarchy. I honestly have no idea how Object's methods are implemented internally by the Smalltalk distro I'm using right now (Squeak), but I know what messages I can send to objects derived from it and how they'll respond to those messages, and that's good enough.

It's not the fact that Perl doesn't prevent you from fiddling with the internals that rubs me the wrong way, it's the fact that you really can't do anything without fiddling.

I'm not trying to bash Perl and I don't think OO is the be-all end-all, but this is one area where, unfortunately, Perl is exceptionally weak. But that's ok, because it's good at everything else :)

[BrentDax]

If that bothers you, just treat the object as a handle used to get at your real implementation:

package My::Class;
our @ISA=qw(Base::Class);
my %obj;

sub new {
    ...
    my $h=$class->SUPER::new;
    
    $obj{$h}{host}=shift;
    $obj{$h}{port}=shift;
    ...
}

sub DESTROY {
    my $h=shift;
    delete $obj{$h};
    $h->SUPER::DESTROY;
}

Now Base::Class could change to using a tied filehandle as its implementation, for all you care.

The reality is that most classes you would want to subclass are designed to make it safe, and even if they aren't there are a few simple measures you can take (like prefixing your subclass's keys with your module's name). And Perl is more than flexible enough for you to do things completely safely if you're really worried.