I think this could be accomodated for in the oft-unused Perl message-signature feature, which right now only takes basic types.

Apoc. 6 went through a total revamp of subroutines signatures. You can still use them like:

sub foo 
{
   my ($bar, $baz) = @_;
   . . . 
}
[download]

If you really want to, but if you did that, you'd be missing out on a lot of really cool stuff. I'm not so sure I personally want rigidly-enforced typing, but some of the signatures make calling conventions easier and make it obvious when we've called something incorrectly. At the same time, little flexibilty is lost over doing a complete check of @_ before we get to the actual code of the subroutine.

Type systems applied to objects is one way to solve the problem of $dog->bark vs. $tree->bark, but I'm not sure if it's the best. Delegation and Traits (both widely talked about in Perl6 development) are potentially much better.

My only OO heresy is that I despise "getter and setter" methods.

Hardly heresy. Having lots of accessors and mutators (i.e., methods which provide direct access to private data) is a sign of poor class design. I won't go as far to say that they should be absolutely forbidden. Whenever I enter such a debate, I hear this Drunken Scottish Object Programmer saying:

Ya can't just spread aaaccessors and muuutators all over your class design there ladie. You're screwwen the whole point!

But then again, maybe I should get the voices in my head checked out.

What's wrong with each providing a run method? If I'm iterating over a collection, I will not be putting both a program and a dog in the same collection. If I do, I probably have a serious confusion in my code. But what if I have a list of animals?

foreach my $animal (@animals) {
    $animal->run;
}
[download]

That's what polymorphism is all about. Fortunately, that's very easy to do in Perl. Perl does provide many of the most useful OO features in Perl. What it lacks is easy to use encapsulation.

As for getters and setters, can you think of any popular language with OO features that doesn't allow them? This isn't a Perl issue as far as I know. It's an issue with programmers treating objects as structs with methods calls. In fact, this is not a Bad Thing, so long as it's used appropriately.

I think this could be accomodated for in the oft-unused Perl message-signature feature, which right now only takes basic types.

Can you provide an example? I'm curious. If you're referring to prototypes (I don't think you are), then you should be aware that those are checked at compile time while method dispatch is resolved at runtime, thus making prototypes useless on method calls.

What's wrong with each providing a run method?

Nothing. However, there is a LOT wrong with weakly typed variables and not requiring arguments to be of certain types, just because they all have 'run' methods does not mean I should be able to interchange programs and dogs. That's just asking for trouble.

As for getters and setters, can you think of any popular language with OO features that doesn't allow them?

I think you meant to say, is there any language that absolutely requires them? In which, no. The argument was in reference to prior comments of Perl OO's system being flexible. My comment was, essentially, as long as Perl doesn't do anything stupid like require getter/setter methods (it won't), I'm ok with a more rigid object structure.

Can you provide an example?

Dog::chewPantleg(Person ted) {
    # implementation
}
[download]

In the above example, you can't have a Dog chew another Dog's pantleg. It's enforced that the argument is a person.

If you're referring to prototypes (I don't think you are)

I am, however weak the current implementation is, that's what I'm talking about. Perl seems to allow OO implementation (a little better than how GTK might implement pseudo-OO in C), but it does not embrace it in spirit. I'm not saying it should be enforced, but it should be embraced.

Then you should be aware that those are checked at compile time while method dispatch is resolved at runtime, thus making prototypes useless on method calls.

I'd like to see that change in Perl6. Maybe it's a pipe dream, but it seems to be a requirement for clean polymorphism.

What's wrong with each providing a run method?

Nothing. However, there is a LOT wrong with weakly typed variables and not requiring arguments to be of certain types, just because they all have 'run' methods does not mean I should be able to interchange programs and dogs. That's just asking for trouble.

This'll throw a runtime error for perl 6. If we can wedge it in, we may do it for perl 5 as well under Ponie, but I wouldn't hold your breath there.

There's a chance that this might also throw a compile time error, but that's even less likely. Possibly a warning, but as there really isn't enough information at compile time to emit one with any reliability... probably not.