OOP: Arrays und Hashs bei inside out Methode

[Annabella]

Hallo :-)

ich habe mir das Buch Perl Best Practices gekauft. In dem Buch wird geraten die inside out Methode zu verwenden.

Ich steig noch nicht so ganz durch, wie ich bei dieser Methode ein Attribut als Hash oder Array deklarieren muss.

use Class::Std::Utils;  
{  
    my %my_hash;  
    my %my_array;  
  
    sub new{  
        my ($class) = @_;  
        my $new_object = bless anon_scalar(), $class;  
        $name_of{ident $new_object} = {};  
        # wie erstelle ich hier jetzt aus %my_hash ein Hash und aus %my_array ein Array?  
    }  
}  

Danke!
Annabella

[Patrick Andrieu]

Hallo Annabella!

Ich steig noch nicht so ganz durch, wie ich bei dieser Methode ein Attribut als Hash oder Array deklarieren muss.

Mir ist das noch zu hoch, aber vielleicht hilft Dir die von Google gefundene »Literatur« zum Thema »inside out method«.

Viele Grüße aus Frankfurt/Main,
Patrick

[Siechfred]

Ich steig noch nicht so ganz durch, wie ich bei dieser Methode ein Attribut als Hash oder Array deklarieren muss.

M.E. immer als Hash, weil der Pfiff bei Inside-Out-Objekten ja gerade der ist, dass die Identifizierung eines Objektes nicht über eine Hashreferenz (klassisch), sondern über eine Scalarreferenz erfolgt. Daher müsstest Du für jede Eigenschaft einen Hash anlegen, dessen Schlüssel die Scalarreferenz ist.

use Class::Std::Utils;

{
    my %my_hash;
    my %my_array;

sub new{
        my ($class) = @_;
        my $new_object = bless anon_scalar(), $class;
        $name_of{ident $new_object} = {};
        # wie erstelle ich hier jetzt aus %my_hash ein Hash und aus %my_array ein Array?
    }
}

  
Kommt drauf an, was %my\_hash und %my\_array sein sollen. Repräsentieren sie die Werte von Eigenschaften? Dann könnte das so aussehen:  
  
~~~perl
$name_of{ident $new_object} = \%my_hash;  
# oder  
$name_of{ident $new_object} = \%my_array;

Sollen es dagegen Eigenschaften sein, könnte es so aussehen:

$my_hash{ident $new_object} = {};  
# oder für %my_array  
$my_array{ident $new_object} = [];

Da Du offenbar bei der Inside-Out-Technik noch am Anfang stehst, solltest Du vielleicht erstmal einen Bogen um die CPAN-Module machen und es von Hand programmieren (zum grundlegenden Verständnis finde ich Inside-out Objects von Randal L. Schwartz sehr gut). Ich bin auch kein Experte auf dem Gebiet und lasse von daher sowas wie Class::InsideOut oder Object::InsideOut erstmal außen vor.

Siechfred

[Annabella]

Hi!

Kommt drauf an, was %my_hash und %my_array sein sollen. Repräsentieren sie die Werte von Eigenschaften? Dann könnte das so aussehen:

Sollen es dagegen Eigenschaften sein, könnte es so aussehen:

wie meinst du das?
Was ist der Unterschied?

Da Du offenbar bei der Inside-Out-Technik noch am Anfang stehst, solltest Du vielleicht erstmal einen Bogen um die CPAN-Module machen und es von Hand programmieren (zum grundlegenden Verständnis finde ich Inside-out Objects von Randal L. Schwartz sehr gut). Ich bin auch kein Experte auf dem Gebiet und lasse von daher sowas wie Class::InsideOut oder Object::InsideOut erstmal außen vor.

die 2 Module Class::InsideOut und Object::InsideOut kannte ich noch nicht.
Sieht für mich relativ kompliziert aus...

ich stehe bei perl allgemein am Anfang ;-)
Erfahrung habe ich mit python und php

Annabella

[Struppi]

ich stehe bei perl allgemein am Anfang ;-)

Ich kann Perl jetzt ca. 10 Jahre und benutzt sowas höchste selten. Du brauchst sowas ja nur um gewisse Aspekte der OO Programmierung 100%ig umzusetzen. Üblicher ist es bei sowas, auf Konventionen auszuweichen, z.b. dass Membervariabeln mit einem Unterstrich anfangen.

Der Punkt bei der Kapselung ist ja: du bist selbst dafür verantwortlich, ob du auf die Eigenschaft direkt oder über die Zugriffsfunktion zugreifst, ist deine Entscheidung, d.h. du machst hier einen relativ hohen Aufwand um etwas nicht tun zu können, was du sowieso nicht tun möchtest. Eigentlich ziemlich unnötig, es sei denn du arbeitest in einem grossen Team und dort sind Schludris die die Doku von dir nicht lesen.

Struppi.

[Annabella]

Hi!

ich stehe bei perl allgemein am Anfang ;-)

Ich kann Perl jetzt ca. 10 Jahre und benutzt sowas höchste selten. Du brauchst sowas ja nur um gewisse Aspekte der OO Programmierung 100%ig umzusetzen. Üblicher ist es bei sowas, auf Konventionen auszuweichen, z.b. dass Membervariabeln mit einem Unterstrich anfangen.

Der Punkt bei der Kapselung ist ja: du bist selbst dafür verantwortlich, ob du auf die Eigenschaft direkt oder über die Zugriffsfunktion zugreifst, ist deine Entscheidung, d.h. du machst hier einen relativ hohen Aufwand um etwas nicht tun zu können, was du sowieso nicht tun möchtest. Eigentlich ziemlich unnötig, es sei denn du arbeitest in einem grossen Team und dort sind Schludris die die Doku von dir nicht lesen.

ich gehe meistens den schwierigeren Weg.

Ich hatte meine Klasse zuerst Hashbasiert aufgebaut. Da ich danach etwas von der inside out Methode gelesen habe, hat mich das interessiert. Was mich interessiert, versuche ich umzusetzen :-)

Annabella

[Struppi]

Ich hatte meine Klasse zuerst Hashbasiert aufgebaut. Da ich danach etwas von der inside out Methode gelesen habe, hat mich das interessiert. Was mich interessiert, versuche ich umzusetzen :-)

Du kannst aber nicht das übliche Konzept mit den "geblesstem" Hash auf die inside out Methode umsetzen. Im Prinzip ist sie nur für einfache Skalare geeignet. D.h. um dann Arrays oder Hashes zu verwenden musst du mit Referenzen arbeiten und u.U. die Zugriffsfunktionen ändern.

Struppi.

[Annabella]

Hi

Ich hatte meine Klasse zuerst Hashbasiert aufgebaut. Da ich danach etwas von der inside out Methode gelesen habe, hat mich das interessiert. Was mich interessiert, versuche ich umzusetzen :-)

Du kannst aber nicht das übliche Konzept mit den "geblesstem" Hash auf die inside out Methode umsetzen. Im Prinzip ist sie nur für einfache Skalare geeignet. D.h. um dann Arrays oder Hashes zu verwenden musst du mit Referenzen arbeiten und u.U. die Zugriffsfunktionen ändern.

dass das nicht 1zu1 umzusetzen geht, ist mir schon bewusst.
Warum ist die Methode nur für einfache Skalare geeignet?
Ist das schlecht, wenn man mit Referenzen arbeitet?

Ich finde das Konzept bis jetzt sauberer :-)

Annabella

[Struppi]

Warum ist die Methode nur für einfache Skalare geeignet?

Naja, weil die Funktionsweise so ist. du hast einen lokalen Hash dessen Werte du mit Setter und Getter manipulierst.

Ist das schlecht, wenn man mit Referenzen arbeitet?

Wie speicherst du denn die Referenzen? Üblicherweise in einem Skalar.

Ich finde das Konzept bis jetzt sauberer :-)

Mir ist irgednwie nicht klar was genau deine Fragestellung ist, natürlich kannst du in einem Skalar auch Referenzen auf ein Array oder Hash speichern. die Frage ist was du erreichen willst? Bei dieser Methode geht es doch darum Attribute zu kapseln, das widersprichst sich eigentlich mit deinem Wunsch dort eine komplexe Struktur speichern zu wollen, das klingt für mich sehr unsauber (falls du den Begriff im zusammenhang mit der OOP verwendest)

Struppi.

[Siechfred]

Naja, weil die Funktionsweise so ist. du hast einen lokalen Hash dessen Werte du mit Setter und Getter manipulierst.

Das Besondere ist doch nur die Verwaltung der Klasse. OOP in Perl verlangt eben nach Umwegen (kann sein, dass das bei Perl 6 mal anders ist), wenn man sowas wie nur lesbare Eigenschaften oder "interne" Funktionen haben will. Letztlich ist der Pferdefuß bei Hashes die Autovivikation, und die "erbst" Du eben, wenn Du deine Klasse an eine Hashreferenz bindest. Dieses Problem hast Du bei InsideOut-Objekten nicht, dafür sind sie halt aufwändiger.

Siechfred

[Struppi]

Naja, weil die Funktionsweise so ist. du hast einen lokalen Hash dessen Werte du mit Setter und Getter manipulierst.

Das Besondere ist doch nur die Verwaltung der Klasse.

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. Wer auf $object->{eigenschaft} zugreift, kennt entweder OOP nicht oder liebt schlechten Stil oder ist sich innerhalb seines Programmes sicher, dass 'eigenschaft' immer so Verfügbar sein wird. Das ist ähnlich wie in JS.

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.

Wobei mir aber immer noch nicht das Problem von Annabella klar ist.

Struppi.

[Siechfred]

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