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)

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;
[download]

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
[download]

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

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 :)

If you don't want to fiddle don't. Declare accessor methods like in the other languages, allocate private dictionary (inside-out-design, or simply __PACKAGE__ or an allocationmethod in the base class TIMTOMTDI), and put your variables into that.

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;
}
[download]

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.