Vererbung (Allgemeines zu Perl)

[thread]13674[/thread]

Vererbung

Leser: 27

Articles: hide open all | hide show old branches

+16 replies
leo11

2009-06-29 20:00

User since
2008-08-14
250 Artikel
BenutzerIn

Hallo.

Mir ist klar, das man Vererbung nutzt um zu sagen: "Das Objekt X ist wie Objekt Y mit ein paar Änderungen. Daher erbe die Dinge von Objekt Y". In Perl klingt das nicht ganz so. An mehreren Stellen wird hervorgehoben, dass Vererbung in Perl lediglich bedeutet, sich Methoden über den vordefnierten Suchweg zugänglich zu machen. Attribute und Konstruktoren werden nicht vererbt.

Nun kann man sich andere Module auch über die use Anweisung anstatt über @ISA = qw ( CD::Music ) zugänglich machen. Würdet ihr mir bitte die beiden Wege voneinander abgrenzen?

Bisher habe ich nur Module gesehen, die mit use arbeiten. Wird Vererbung häufig eingesetzt?
Last edited: 2009-06-29 20:02:41 +0200 (CEST)
- +14 replies
- pq
  
  2009-06-29 20:30
  User since
  2003-08-04
  12208 Artikel
  Admin1
  Konstruktoren werden auf jeden Fall vererbt, denn ein Konstruktor ist auch nichts anderes als eine (Klassen-)Methode. Wenn also Y von X erbt, und Y keine eigenen Methoden hat, dann ruft Y->new die new-Methode von X auf.
  
  Was meinst du mit "Attribute werden nicht vererbt"? Schreibt man einen Accessor für das Attribut "foo" in X, dann kann ein Objekt der Klasse Y selbstverständlich auch diesen Accessor aufrufen. Man kann sich das aber auch vereinfachen, indem man Class::Accessor, Moose o.ä. benutzt.
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7
  
  package X; use base qw/ Class::Accessor /; X->mk_accessors( qw/ foo bar / ); ... package Y; use base 'X'; # nun hat auch Y die Attribute foo und bar
  
  Im Gegensatz zu
  use base qw/ CD::Music /
  hat ein
  use CD::Music
  gar nichts mit Vererbung oder OOP zu tun. Man muss zunächst einmal unterscheiden, ob man mit einem use auch Subroutinen importiert oder nicht. Ein use ist aber in jedem Fall nötig, um das Modul überhaupt zu laden.
  
  Es gibt Module wie z.b. File::Basename, von denen man einzelne nützliche Funktionen importieren kann:
  
  Code (perl): (dl )
  
  1 2
  
  use File::Basename qw/ dirname /; my $path = dirname($fullpath);
  
  es geht aber theoretisch auch so:
  
  Code (perl): (dl )
  
  1 2
  
  use File::Basename; my $path = File::Basename::dirname($fullpath);
  
  Ist natürlich mehr Schreibarbeit und erhöht sie Unlesbarkeit, sobald die Funktion mehrmals aufgerufen wird.
  Indem die Subroutine dirname in dein aktuelles Package importiert wird, könnte man es allerdings auch als Methode aufrufen, was aber nicht Sinn der Sache ist. Deswegen sollte man sparsam mit Importen sein.
  Alternativ dazu gibt es den Weg, den File::Spec geht:
  
  Code (perl): (dl )
  
  1 2
  
  use File::Spec; my $path = File::Spec->catfile( qw/ a b c / );
  
  Alle "Subroutinen" werden hier einfach als Klassenmethoden aufgerufen. Das ist natürlich auch mehr Tipparbeit, aber IMHO schöner als File::Basename::dirname, weil es als Klassenmethode auch Vererbung erlaubt.
  
  Man kann sagen, das spezielle an Perl ist, dass es einfach alles nur Subroutinen sind und man sie auf verschiedene Arten aufrufen kann, aber nicht alle Aufrufmethoden immer Sinn ergeben, z.b. wäre File::Basename->dirname ein falscher Aufruf.
  
  Dann gibt es Module wie z.b. CGI.pm, die selber objektorientiert sind (bei CGI.pm ist es sogar optional):
  
  Code (perl): (dl )
  
  1 2 3
  
  use CGI; my $cgi = CGI->new; print $cgi->param("foo");
  
  Deine Frage "Wird Vererbung häufig eingesetzt?" kann man so eigentlich nicht beantworten. Was ist häufig?
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +12 replies
  - leo11
    
    2009-06-29 21:03
    User since
    2008-08-14
    250 Artikel
    BenutzerIn
    
    2009-06-29T18:30:15 pq
    Konstruktoren werden auf jeden Fall vererbt, denn ein Konstruktor ist auch nichts anderes als eine (Klassen-)Methode. Wenn also Y von X erbt, und Y keine eigenen Methoden hat, dann ruft Y->new die new-Methode von X auf.
    
    Soweit klar.
    
    Quote
    Was meinst du mit "Attribute werden nicht vererbt"?
    
    In "Object Oriented Perl" aus dem Jahr 2000 steht dazu folgendes:
    "..., it's important to realize that inheritance in Perl is merely a way of specifiying where to look for a method and nothing else. There is no direct inheritance of attribute - unless you arrange for it - nor any hierarchical calling of constructors or destructors - unles you explicitly write those methods that way..."
    
    Quote
    Im Gegensatz zu
    use base qw/ CD::Music /
    hat ein
    use CD::Music
    gar nichts mit Vererbung oder OOP zu tun.
    
    Versteh ich nicht. Ist das erste eine alternative Schreibweise für
    
    Code (perl): (dl )
    
    @ISA = qw / CD::Music /
    
    Quote
    Ein use ist aber in jedem Fall nötig, um das Modul überhaupt zu laden.
    
    Auch bei Vererbung?
    
    Quote
    Deine Frage "Wird Vererbung häufig eingesetzt?" kann man so eigentlich nicht beantworten. Was ist häufig?
    
    Bei der Beschreibung der Nebenwirkungen von Arzneimitteln 1 bis 10 von 100. (-;
    - +2 replies
    - pq
      
      2009-06-29 21:51
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      2009-06-29T19:03:10 leo11
      Versteh ich nicht. Ist das erste eine alternative Schreibweise für
      
      Code (perl): (dl )
      
      @ISA = qw / CD::Music /
      
      fast.
      
      Code (perl): (dl )
      
      use base qw/ CD::Music /;
      
      entspricht
      
      Code (perl): (dl )
      
      1 2
      
      use CD::Music; # oder require statt use our @ISA = qw/ CD::Music /;
      
      Quote
      Quote
      Ein use ist aber in jedem Fall nötig, um das Modul überhaupt zu laden.
      
      Auch bei Vererbung?
      
      ja, natürlich. mit einem use oder require wird das modul geladen und kompiliert. wenn du nur @ISA veränderst, passiert erstmal gar nichts.
      
      Quote
      Bei der Beschreibung der Nebenwirkungen von Arzneimitteln 1 bis 10 von 100. (-;
      
      kann man trotzdem nicht beantworten =)
      man kann sicher sagen, in Javaz.b. wird mehr Vererbung benutzt, weil da einfach so ziemlich alles eh ein Objekt ist.
      Ansonsten könnte man alle Module zählen und schauen, wie viele use base, use parent (neuere alternative zu base) benutzen oder @ISA verändern.
      Ich kann nur von mir selber sagen, dass ich bei grösseren Projekten meist objektorientiert arbeite, nur bei kleineren Helferlein nicht.
      
      Zusätzlich/alternativ zu Vererbung gibt es übrigens auch mixin (evtl. auch andere Implementierungen mittlerweile). damit erbt man sozusagen auch, aber nur bestimmte methoden; das kann ganz praktisch sein anstelle mehrfachererbung. (klassisches beispiel ist das viereck mit den unterklassen raute und rechteck, und ein quadrat ist gleichzeitig eine raute und ein rechteck)
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - leo11
        
        2009-06-29 22:10
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Vielen Dank.
    - +9 replies
    - sid burn
      
      2009-06-29 23:22
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Quote
      In "Object Oriented Perl" aus dem Jahr 2000 steht dazu folgendes:
      "..., it's important to realize that inheritance in Perl is merely a way of specifiying where to look for a method and nothing else. There is no direct inheritance of attribute - unless you arrange for it - nor any hierarchical calling of constructors or destructors - unles you explicitly write those methods that way..."
      
      Grundsätzlich gesehen bietet dir Pure Perl etwas wie Attribute nicht an. So wie im Text erwähnt werden Methoden vererbt das war es.
      
      Wenn du eine Klasse X hast und du hast eine Klasse Y die von X ableitet, dann kannst du in Y einen eigenen Konstruktor bauen. Es wird aber nicht automatisch der Konstruktor von X aufgerufen, weder werden irgendwelche Initialisierungen die X gemacht hat automatisch vorgenommen. Du musst also alles selber manuell Programmieren, und auch beim Programmieren darauf achten das du deine Klassen entsprechend offen hälst.
      
      In der Regel bedeutet dies, das du z.B. einen Konstruktor "new" hast und eine weitere Methode z.B. "init()" damit eine vererbte Klasse die init() Methode der übergeordneten Klasse aufrufen kann, und so deine Klasse Y auch die Initialisierungen vornehmen kann die X gemacht hat.
      
      Automatisch passiert es also nicht, du musst den großteil selber Programmieren. Aber hier würde sich z.B. z.B. Moose empfehlen. Ein OOP Framework in Perl das dir all dies abnimmt, und du soetwas nicht mehr manuell machen musst.
      
      Bei Moose kannst du dann auch wirklich Attribute definieren und deine verbte Klasse kennt automatisch die Attribute des Parents. Weiterhin werden Initialisierungen etc. automatisch für dich in der Korrekten Reihenfolge etc. aufgerufen.
      
      Der Gebrauch von Moose empfiehlt sich schon sehr.
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
      - +8 replies
      - LanX-
        
        2009-06-30 00:25
        
        User since
        2008-07-15
        1000 Artikel
        BenutzerIn
        
        2009-06-29T21:22:34 sid burn
        Grundsätzlich gesehen bietet dir Pure Perl etwas wie Attribute nicht an. So wie im Text erwähnt werden Methoden vererbt das war es.
        
        Naja, vererbbare Attribute kann man IMHO mit Lvalue-Methoden ganz gut simulieren.
        
        Nachtrag: Grundsätzlich
        
        Es gibt IMHO nicht sowas wie DAS Standard-Objektmodell und DIE Standard Terminologie. Heutzutage ist Java hip, nichtsdestotrotz sollte doch bei Vergleichen bitte dazugesagt werden WOMIT man Perl vergleicht.
        
        Blanke Aussagen wie "Perl kennt keine Attribute" sind so sinnig wie "Susis haben keine ~~Titten~~ Brüste"
        
        sonst können wir uns gleich darauf einigen dass Java die einzige OOP Sprache ist.
        Last edited: 2009-06-30 01:07:34 +0200 (CEST)
        me and my writeups
        
        +7 replies
        
        sid burn
        
        2009-06-30 00:55
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Naja, vererbbare Attribute kann man IMHO mit Lvalue-Methoden ganz gut simulieren.
        
        Und warum sollte das mehr "vererbbare Attribute" sein als eine normale Get/Setter Methode?
        
        Das einzige was du an einer Lvalue Mathode hast ist eine andere Schreibweise, ansonsten bietet es dir das gleiche wie eine normale Get/Setter Methode.
        
        Quote
        Nachtrag: Grundsätzlich
        
        Es gibt IMHO nicht sowas wie DAS Standard-Objektmodell und DIE Standard Terminologie. Heutzutage ist Java hip, nichtsdestotrotz sollte doch bei Vergleichen bitte dazugesagt werden WOMIT man Perl vergleicht.
        
        Blanke Aussagen wie "Perl kennt keine Attribute" sind so sinnig wie "Susis haben keine ~~Titten~~ ähm Brüste"
        
        Ein Grundsätzliches Schema der Objektorientierung gibt es sehrwohl. Vererbung, Delegation etc. sind alles Konzepte und sind nicht an einer Programmiersprache gebunden. Wenn ich von Vererbung rede muss ich nicht dazu sagen welche programmiersprache ich meine.
        
        Es gibt Programmiersprachen die OOP besser und weniger gut unterstützen, oder es etwas anders machen. Trotzdem bleibt das Konzept Objektorientierung so wie es ist.
        
        Ansonsten wenn ich es mal so sagen muss, ist das was dir Perl als Standard OOP anbietet eher bescheiden wenn nicht sogar grotten schlecht. Aber Gott sei dank ist Perl flexibel und erweiterbar und beschert tolle dinge wie Moose.
        
        Das einzige was ich dann schon wieder sehe ist dieses Fanboy getue auch von dir. Über alles andere wird schlecht geredet, sobald es dann aber um Perl geht wird schnell wieder die defensive Haltung angezogen.
        
        Zum Beispiel hast du hier ja auch paar Posts dadrunter ohne Probleme eine Aussage gemacht das JavaScript ja eigentlich kein richtige Klasse kennt. (Klar ist ja wieder Protyp basierend, ist ja wieder kein "echtes" OOP). Aber dir selber bei dein eigenes Motto treu bleiben tust du dir ja anscheind auch nicht.
        
        Wenn es dann aber um Perl geht wo man Kritik rausliest das dort ja wieder was nicht "echt" oder "richtig" ist dann muss man ja auf einmal schnell sagen mit welchen Sprachen man es vergleicht weil die aussagen ja sonst Praktisch totaler Schwachsinn ist.
        
        blablabla...
        Last edited: 2009-06-30 00:59:49 +0200 (CEST)
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        +4 replies
        
        LanX-
        
        2009-06-30 13:30
        
        User since
        2008-07-15
        1000 Artikel
        BenutzerIn
        
        Bzgl ...
        
        ... "Fanboy": Mich nervt das OOP in Perl ... Fanboy getue erkennen ich höchstens bei dir und Moose.
        
        ... "Javascript": Bei Javascript ist ja klar womit ichs vergleiche ...Perl. Die meisten vertreten es gebe gar keine Klassen in JS, ich habs relativiert. Hier genau das gleiche Problem bei der Kritik wird das Klassenverständnis aus Java entlehnt. Es gibt aber sehr wohl Objekte die wg des gleichen Konstruktors einer gemeinsamen Gruppe (oder Klasse) angehören.
        
        ... "...nicht an einer Programmiersprache gebunden~~Was Attribute sind ist klar~~": Bitte gib mir eine Referenz wo das verlässlich definiert wurde, insbesondere dass "echte Attribute" vererbbar seien.
        
        Für mein Verständnis sind die Elemente der geblessten Datenstruktur in Perl Attribute, schon alleine im Wortsinne von "Attribut".
        
        Grundsätzlich: Es macht keinen Sinn über ein Thema zu diskutieren, wenn die Begrifflichkeiten divergieren. Meinetwegen das Javamodell hinzuziehen, aber dann bitte dazusagen.
        
        Sonst endet es in Definitionstreitigkeiten wie jetzt.
        Last edited: 2009-06-30 15:49:54 +0200 (CEST)
        me and my writeups
        
        +3 replies
        
        sid burn
        
        2009-07-03 11:31
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        2009-06-30T11:30:18 LanX-
        ... "Javascript": Bei Javascript ist ja klar womit ichs vergleiche ...Perl.
        
        Umso lächerlicher ist es ja auch. Du sagst ganz klipp und klar das JavaScript keine echten Klassen kennt. Verglichen mit Perl? Perl kennt technisch ebenfalls keine Klassen.
        
        Quote
        Die meisten vertreten es gebe gar keine Klassen in JS, ich habs relativiert.
        
        Nein, hast du nicht. Bisher wurde nichtmal JS erwähnt, Und in einem Satz zu sagen das JS ja eigenltich keine Klassen kennt, daran ist nichts relativitiert. Relativitiert hättest du es wenn du gesagt hättest das es egal wäre, und das es aussieht wie echten Klassen oder sonst irgendetwas, aber das tatest du ja nicht.
        
        Quote
        Hier genau das gleiche Problem bei der Kritik wird das Klassenverständnis aus Java entlehnt.
        
        Ich habs nicht. Da ich Java nicht kann und nie gelernt habe, entwende ich daraus auch nichts.
        
        Quote
        Es gibt aber sehr wohl Objekte die wg des gleichen Konstruktors einer gemeinsamen Gruppe (oder Klasse) angehören.
        
        Was auch immer du genau meinst spielt eigentlich keine Rolle, da ich diesbezüglich ja nichts dagegen gesagt habe.
        
        Quote
        ... "...nicht an einer Programmiersprache gebunden~~Was Attribute sind ist klar~~": Bitte gib mir eine Referenz wo das verlässlich definiert wurde, insbesondere dass "echte Attribute" vererbbar seien.
        
        1) Ich sprach nirgendswo von "echten Attributen".
        2) Ich sprach nirgendswo davon das "echte Attribute" vererbbare wären.
        3) Durch dein explizit hinweisen auf "verlässlich" kann ich schon erkennen das jede Diskussion mit der damit unbrauchbar ist. Verlinke ich Wikipedia, ist es nicht verlässlich, verlinke ich hunderte kleine Seiten, sind sie ja auch nicht verlässlich. Was wäre den verlässlich deiner Meinung nach? Nebenbei Damian Conway in seinem OOP Buch sagt ja selber das es in Perl keine Attribute gibt, der text dazu wurde hier ja schon sogar zitiert, aber lass mich raten. Nicht verlässlich?
        4) Wenn man über etwas Diskutiert müssen beide Gesprächspartner eine Vorstellung von dem Thema haben. Wo ist dein Link mit deiner Referenz das es sagt das das alles nicht so wäre?
        
        Quote
        Für mein Verständnis sind die Elemente der geblessten Datenstruktur in Perl Attribute, schon alleine im Wortsinne von "Attribut".
        
        Für mich nicht. Für mich bleibt eine Datenstruktur eine Datenstruktur, unabhängig davon ob ich sie blesse oder nicht. Attribute sind Eigenschaften die eine Klasse besitzt.
        
        In Perl schreibt man letztendlich Methoden (bzw. technisch normale Funktionen) womit man dann auf die Attribute zugreift und setzt. Trozdem hat man in einer klasse keine Attribute definiert sondern man arbeitet eben nur auf einer Datenstruktur.
        
        Datenstruktur ist auch deswegen unpassend da ich ein Skalar oder auch eine Subroutine oder Regex als grundbaustein des Objektes nehmen kann. Deswegen sehe ich eine Datenstruktur auch nicht als Attribute an.
        
        Vorallem da ein Hash ja auch beliebiges annehmen und speichern kann. Greife ich einfach auf die Datenstruktur zu dann versteht die Klasse trotzdem nicht mehr an Attributen. Wenn ich also "$obj->{neues_attribut} = 'asd'" mache habe ich nicht automagisch ein neues Attribut.
        
        Attribute definieren sich in Perl alleine durch deine Funktionen, und das was du programmiert hast. Die Datenstruktur bildet weder Attribute direkt ab, noch spielt es eine rolle was du wirklich blessed.
        
        Quote
        Grundsätzlich: Es macht keinen Sinn über ein Thema zu diskutieren, wenn die Begrifflichkeiten divergieren. Meinetwegen das Javamodell hinzuziehen, aber dann bitte dazusagen.
        
        Ich ziehe kein Javamodel hinzu, da ich nicht über Java rede. OOP ist allgemeingültig und wird nicht erst durch eine Implementation definiert. Das wäre auch total sinnlos wenn es so wäre.
        
        Dann kann man nämlich nicht darüber Diskutieren, da ja jede Sprache es so implementiert wie sie meint es richtig ist, und dann ja auch automatisch alles richtig sein muss wenn die Definition bei der Implementierung liegt und nicht allgemeingültig wäre.
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        sid burn
        
        2009-07-03 12:06
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Und um es vielleicht besser datzustellen.
        
        Mir persönlich ist es ziemlich egal wie es technisch nun "wirklich" oder "echt" ist, da es für denjenigen der es nutzt absolut irrelevant ist.
        
        Generell halte ich diese ganzen Diskussionen ums "echt" oder "nicht echt" auch für total unnötig. Für mich sind das meist billige Schein Argumente wenn z.B. jemand sagt Perl hätte ja gar keine echte OOP.
        
        Das ist volkommen irrelevant. Für jemanden der es nutzt hat er Klassen und kann Objekte erzeugen, und Methoden aufrufen das dieses Objekt bearbeitet oder damit arbeitet.
        
        Auch wenn technisch gesehen nur referenzen übergeben wird.
        
        Das ist letztendlich die "höhere" Eben wie man es sieht. Wenn man allerdiengs die OOP von Perl selber lernt oder wissen möchte wie sie funktioniert, und das muss man unweigerlich wenn man OOP Programmieren möchte in Perl, dann muss man eben die technische Seite kennen, und technisch bietet Perl eben nicht besonders viel und kennt dort sehr wenig Abstraktion.
        
        Ich kann halt nicht direkt Attribute definieren, sondern Attribute definieren sich durch Funktionen die ich schreibe und wenn ich sage, "das ist nun ein attribut".
        
        Technisch gesehen bietet es dort keine Abstraktion dafür und da muss ich keine andere Sprache zum vergleich herziehen um soetwas zu erkennen.
        
        Der Punkt der mich dann aufstößt ist dass sobald man soetwas dann sagt auf einmal direkt jemand kommen muss und man ja soetwas ja eigentlich nicht einfach sagen könne und das gesagte ja eigentlich totaler schwachsinn wäre. Gleichzeitig sieht man dann aber wie genau der gleiche die selbe aussage nur über eine andere Programmiersprache fällt.
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        LanX-
        
        2009-07-03 23:18
        
        User since
        2008-07-15
        1000 Artikel
        BenutzerIn
        
        Quote
        Umso lächerlicher ist es ja auch. Du sagst ganz klipp und klar das JavaScript keine echten Klassen kennt. Verglichen mit Perl? Perl kennt technisch ebenfalls keine Klassen.
        
        "Because a class in Perl is really just a package"
        http://perldoc.perl.org/perltooc.html
        
        Quote
        Nein, hast du nicht. Bisher wurde nichtmal JS erwähnt, Und in einem Satz zu sagen das JS ja eigenltich keine Klassen kennt, daran ist nichts relativitiert.
        
        Der OP meinte die Vererbung liefe von Objekt zu Objekt und ich fragte ob er JS meine. Der Kontext ist also klar.
        
        Klassenlose Vererbung ist ein verbreitete Floskel um JS zu beschreiben. Crockford selbst bespricht ein Muster von "pseudoklassicher Vererbung".
        
        Quote
        1) Ich sprach nirgendswo von "echten Attributen".
        
        stimmt du hast noch nicht mal "echt" gesagt
        
        Quote
        Grundsätzlich gesehen bietet dir Pure Perl etwas wie Attribute nicht an.
        
        "Data fields peculiar to each object are often called instance data or object attributes, and data fields common to all members of that class are class data, class attributes, or static data members."
        http://perldoc.perl.org/perltoot.html
        
        Quote
        Nebenbei Damian Conway in seinem OOP Buch sagt ja selber das es in Perl keine Attribute gibt, der text dazu wurde hier ja schon sogar zitiert, aber lass mich raten. Nicht verlässlich?
        
        Was leider falsch ist, in 1.1.1 definiert er Objektattribute und 1.1.3 heißt sogar "Klassenattribute und Methoden"
        
        Um das ganze einer Versachlichung zuzuführen werde ich bei Gelegenheit ein OO Glossar im Wiki einstellen, dass ich schamlos bei Conway's "Objektorientierte Programmierung mit Perl" abschreiben werde, er hat sich nämlich einige Mühe gegeben die Terminologie mit anderen Sprachen abzustimmen.
        
        Last edited: 2009-07-04 04:41:50 +0200 (CEST)
        me and my writeups
        
        +2 replies
        
        LanX-
        
        2009-06-30 13:48
        
        User since
        2008-07-15
        1000 Artikel
        BenutzerIn
        
        2009-06-29T22:55:05 sid burn
        Quote
        Naja, vererbbare Attribute kann man IMHO mit Lvalue-Methoden ganz gut simulieren.
        
        Und warum sollte das mehr "vererbbare Attribute" sein als eine normale Get/Setter Methode?
        
        Das Handling eines Attributzugriffs wird besser simuliert!
        
        Extremfall: Realisiere mal $self->a++ mit Getter und Settern ... (klassischerweise wird hier mal schnell aus der Not noch eine Methode inc_a() geboren ... und dec_a() usw.)
        
        2009-06-29T22:55:05 sid burn
        Das einzige was du an einer Lvalue Mathode hast ist eine andere Schreibweise, ansonsten bietet es dir das gleiche wie eine normale Get/Setter Methode.
        
        nicht das gleiche manchmal sogar weniger, um eine Filterung im Setter zu gewährleisten kann ich bei lvalue-methoden nur auf tie zurückgreifen.
        Das funktioniert zwar sehr gut ist aber Faktor 10 langsamer als ein setter, weil tie blöderweise selbst einen ~~Objekt~~Methodenaufruf generiert...
        Last edited: 2009-06-30 14:24:58 +0200 (CEST)
        me and my writeups
        
        sid burn
        
        2009-07-03 11:44
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        2009-06-30T11:48:29 LanX-
        Das Handling eines Attributzugriffs wird besser simuliert!
        
        Aha, verglichen zu was den? Ich meine du bist ja derjenige der Pocht es mit einer Sprache zu vergleichen. Es wird besser simuliert verglichen zu welcher Sprache?
        
        Unabhängig davon teile ich deine Meinung von Attributen und vergleich zu Sprachen ja nicht. Attribute sind eigenschaften von Klassen. Und durch eine andere Syntaxschreibweise wird es nicht mehr oder weniger zu einem Attribut.
        
        Quote
        Extremfall: Realisiere mal $self->a++ mit Getter und Settern ... (klassischerweise wird hier mal schnell aus der Not noch eine Methode inc_a() geboren ... und dec_a() usw.)
        
        Das ist toll das mit Lvalue so ein Fall schöner und leichter ist, dadurch wird es aber nicht mehr zu Attributen oder weniger.
        
        Oder wird OOP neuerdings durch Syntax definiert, und ist kein Konzept mehr?
        Last edited: 2009-07-03 11:51:55 +0200 (CEST)
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - sid burn
    
    2009-06-29 22:59
    
    User since
    2006-03-29
    1520 Artikel
    BenutzerIn
    
    Quote
    Ist natürlich mehr Schreibarbeit und erhöht sie Unlesbarkeit, sobald die Funktion mehrmals aufgerufen wird.
    Indem die Subroutine dirname in dein aktuelles Package importiert wird, könnte man es allerdings auch als Methode aufrufen, was aber nicht Sinn der Sache ist. Deswegen sollte man sparsam mit Importen sein.
    Alternativ dazu gibt es den Weg, den File::Spec geht
    
    Man kann auch namespace::clean oder wenn man Moose nutzt namespace::autoclean nutzen.
    
    Dadurch kann man die Subroutinen Importieren und die kurze schreibweise nutzen, und es erscheint trotzdem nicht als Klassenmethode.
    
    Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- LanX-
  
  2009-06-29 21:03
  
  User since
  2008-07-15
  1000 Artikel
  BenutzerIn
  
  2009-06-29T18:00:37 leo11
  Mir ist klar, das man Vererbung nutzt um zu sagen: "Das Objekt X ist wie Objekt Y mit ein paar Änderungen. Daher erbe die Dinge von Objekt Y".
  
  Nee du wirfst da einiges durcheinander, nicht Objekte erben sondern die Klassen zu denen die Objekte (Instanzen) gehören.
  
  In fast allen OO-Sprachen wird das so gehandhabt, welche kennst du den schon?
  
  Was du beschreibst ist eher Javascript wo's keine Klassen (im üblichen Sinne) gibt...
  Last edited: 2009-06-29 21:10:58 +0200 (CEST)
  me and my writeups

View all threads created 2009-06-29 20:00.