Ja und Zweck des ganzen ist es mit echten privaten Objektvariabeln arbeiten zu können und setter und getter einzusetzen. Was aber lediglich eine Frage des Programmierstils ist.
D'accord.
Wer auf $object->{eigenschaft} zugreift, kennt entweder OOP nicht oder liebt schlechten Stil
Da begibst Du Dich IMO auf sehr dünnes Eis, integraler Bestandteil von OOP sind nicht nur Methoden, sondern auch Eigenschaften. Dass der Zugriff darauf in Perl so aussieht, wie Du beschrieben hast, hängt ja letztlich nur mit der Verwaltung der Klasse via Hashreferenz zusammen. In Perl 6 wird's das nicht mehr geben, da heißt es $object.method
ebenso wie $object.property
. Dann wird es auch private Objektvariablen und -methoden sowie nur lesbare Variablen geben, ohne dass man sich mit InsideOut-Objekten plagen muss.
Die Frage die sich mir dabei stellt ist ob sich der Aufwand lohnt, eine Eigenschaft einer Programmiersprache auszuhebeln, vermutlich mit dem Performancenachteilen, weil man befürchtet es gebe schlampige Programmierer die mit dem Code Arbeiten. Falls man diese Frage mit Ja beantworten muss ist das sicher eine gute Lösung.
Ich sehe das vor dem Hintergrund von Vertippsern:
use strict;
my $object = myObj->new;
# auto vivication trap
$object->{naem} = 'foo';
# wtf is foo?
print $object->{name};
package myObj;
use strict;
sub new {
my $class = shift;
my $hr = { name => 'Siechfred' };
my $obj = bless $hr, $class;
return $obj;
}
Bei solchen Fehlern suchst Du Dir einen Wolf, das passiert bei InsideOut nicht, das Script würde sterben.
Wobei mir aber immer noch nicht das Problem von Annabella klar ist.
Ich fürchte, dass sie das Konzept noch nicht verstanden hat, es aber wegen ihres Buches "besser" machen möchte.
Siechfred
Hinter den Kulissen passiert viel mehr, als man denkt, aber meistens nicht das, was man denkt.