Nicht benötigte Argumente trotzem in eine Variable kopieren? (Allgemeines zu Perl)

[thread]20430[/thread]

Nicht benötigte Argumente trotzem in eine Variable kopieren?

Leser: 19

Articles: hide open all | hide show old branches

+30 replies
Kuerbis

2018-02-22 08:19
User since
2011-03-20
947 Artikel
BenutzerIn
Hallo,

ist es in Ordnung, nicht benötigte Argumente zu ignorieren?
Code (perl): (dl )

1 2 3

sub databases { return [ '/home/me/demo.sqlite' ]; }
anstatt
Code (perl): (dl )

1 2 3 4

sub databases { my ( $self, $parameter ) = @_; return [ '/home/me/demo.sqlite' ]; }
- Raubtier
  
  2018-02-22 08:51
  
  User since
  2012-05-04
  1075 Artikel
  BenutzerIn
  
  Merkwürdige Frage, finde ich.
  
  Wird die Funktion denn mit Argumenten aufgerufen? Wenn ja, dann wäre es ja schon sehr komisch, diese zu ignorieren.
  
  Wenn nein, dann sehe ich die Notwendigkeit nicht, @_ zu verwenden.
  
  Und bei dir kommt noch das $self hinzu. Ist deine Funktion eine Member-Funktion? Wenn ja, warum?
  
  Also konkret: mir ist nicht klar, warum du hier überhaupt die Variante mit my ( $self, $parameter ) = @_; in Betracht ziehst.
- rosti
  
  2018-02-22 08:52
  User since
  2011-03-19
  3474 Artikel
  BenutzerIn
  Die Frage ist doch eher, wie man seine Funktionen organisiert. Spätestens seit OOP in Perl Einzug hielt ( so ab dem Jahr 2000 etwa ), sollte sich der Begriff Namespace herumgesprochen haben. D.h., daß man Funktionen vorzugsweise mit dem Namen einer Klasse oder mit dem Namen einer Instanz aufruft -> da findet immer eine Übergabe statt.
  
  Es sei denn man hält an der Konvention namespace::function() fest, aber auch in diesem Fall gibt es @_ auch dann wenn nichts drinsteht.
  
  In Methoden für Instanzen jedenfalls, würde ich grundsätzlich immer kenntlich machen, daß es Methoden von Instanzen sind. Also ein
  
  Code (perl): (dl )
  
  1 2 3
  
  sub foo{ my $self = shift; }
  
  notieren, auch dann wenn keine weiteren Argumente im Spiel sind. Ein Array mit Pfaden zurückzugeben macht übrigens nur dann einen Sinn, wenn all diese Pfade in der Anwendung eine Rolle spielen. Wenn es nur ein Pfad ist, lohnt es sich über einen dafür assoziierten Namen nachzudenken, also wie man seine ganze Konfiguration aufbaut. Ein Aufruf zur Herstellung einer Sitzung könnte dann so aussehen:
  
  Code (perl): (dl )
  
  my $dbh = $self->dbh('dbname');
  
  was ich persönlich zweckmäßiger finde, als in der Anwendung ein Array durchgehen zu müssen. Und wenn der Name der DB schon vor der Instanzerstellung feststeht, könnte man den ganzen Kram auch im Konstruktor erledigen ;)
  
  MfG
- +12 replies
- Kuerbis
  
  2018-02-22 13:30
  User since
  2011-03-20
  947 Artikel
  BenutzerIn
  Wenn ich mir das jetzt nochmal anschaue, dann habe ich den Eindruck, dass ich nicht genug Informationen geliefert habe.
  Es geht hier um ein kurzes Beispiel für das hier beschriebene API.
  
  Hier das Beispiel mit den - wie hier vorgeschlagen - expliziten $self:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
  
  package App::DBBrowser::DB::MyPlugin; use warnings; use strict; use DBI; sub new { my ( $class, $info ) = @_; bless $info, $class; } sub driver { my ( $self ) = @_; return 'SQLite'; } sub db_handle { my ( $self, $db ) = @_; my $dbh = DBI->connect( "DBI:SQLite:dbname=$db", '', '', { RaiseError => 1, PrintError => 0, sqlite_unicode => 1, }) or die $DBI::errstr; return $dbh; } sub databases { my ( $self ) = @_; return [ '/home/me/demo.sqlite' ]; } 1;
  - Muffi
    
    2018-02-22 13:37
    
    User since
    2012-07-18
    1465 Artikel
    BenutzerIn
    
    Ist wohl Geschmackssache. Ich würd alle Parameter, mit denen die Methoden aufgerufen werden mit aufführen.
    1 + 1 = 10
  - +5 replies
  - hlubenow
    
    2018-02-22 16:13
    
    User since
    2009-02-22
    875 Artikel
    BenutzerIn
    
    Das ist ja eine sehr merkwürdige Konstruktion.
    Mit dem Wort "package ...", der Funktion new() und darin bless() wird eine Klasse definiert.
    Die Variable $self enthält normalerweise die Attribute, die in der Klasse verwendet werden (vgl. mein Beispiel).
    Hier ist in new() aber gar kein $self.
    
    In den Funktionen innerhalb einer Klasse (den "Methoden") muß immer dieses $self am Anfang übergeben werden, damit die Attribute auch in der Methode verfügbar sind, und damit deutlich wird, daß es sich nicht um eine alleinstehende Funktion handelt, sondern um eine Methode innerhalb einer Klasse.
    Insofern wäre die Antwort auf Deine Frage: In databases() kannst Du $parameter weglassen, weil Du ihn nicht verarbeitest. Aber das $self wegzulassen, obwohl es sich um eine Methode innerhalb einer Klasse handelt, geht normalerweise nicht; und hier geht es zumindest aus Gründen des Programmierstils auch nicht.
    
    Ich hätte auch in new() das $self mit definiert, auch wenn es leer ist.
    Das ist irgendwie auch nötig, sonst kannst Du den Methoden ja gar nichts Sinnvolles für $self übergeben.
    Last edited: 2018-02-22 16:25:49 +0100 (CET)
    - +4 replies
    - Kuerbis
      
      2018-02-22 17:04
      
      User since
      2011-03-20
      947 Artikel
      BenutzerIn
      
      In $info sind Informationen drinnen, habe aber noch nicht daran gedacht, dass man das $self nennt.
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
      
      sub databases { my ( $self ) = @_; return \@ARGV if @ARGV; my $dirs = $self->{dirs_sqlite}; my $cache_key = $self->{plugin} . '_' . join ' ', @$dirs; my $ax = App::DBBrowser::Auxil->new(); my $db_cache = $ax->read_json( $self->{db_cache_file} ); if ( $self->{sqlite_search} ) { delete $db_cache->{$cache_key}; } my $databases = []; if ( ! defined $db_cache->{$cache_key} ) { print 'Searching...' . "\n"; for my $dir ( @$dirs ) { File::Find::find( ... push @$databases, ... ... ); } print 'Ended searching' . "\n"; $db_cache->{$cache_key} = $databases; $ax->write_json( $self->{db_cache_file}, $db_cache ); } else { $databases = $db_cache->{$cache_key}; } return $databases; }
      - +3 replies
      - hlubenow
        
        2018-02-22 23:56
        
        User since
        2009-02-22
        875 Artikel
        BenutzerIn
        
        2018-02-22T16:04:34 Kuerbis
        In $info sind Informationen drinnen, habe aber noch nicht daran gedacht, dass man das $self nennt.
        
        Ok, meine Seite orientiert sich sehr an Python, da nennt man das "self". Der Interpreter würde auch ein anderes Wort verstehen, aber "self" ist eine "starke Konvention", das heißt, alle nennen das so (und der Psychopath, der weiß, wo man wohnt, würde sauer, wenn man es anders nennen würde).
        Zu Perl findet man das "$self" aber auch z.B. in "perldoc perlootut", also wird das schon so sein.
        Zu beachten ist, daß man für "$self" nichts als Argument mit übergibt, wenn man eine Klassenmethode von außen aufruft. Beispiel:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
        
        #!/usr/bin/perl use warnings; use strict; package Box { sub new { my $classname = shift; my $self = {content => 1}; return bless($self, $classname); } sub addContent { my $self = shift; my $addition = shift; $self->{content} += $addition; } sub showContent { my $self = shift; print $self->{content}; print "\n"; } } my $box = Box->new(); $box->addContent(5); $box->showContent();
        
        Es heißt also nur "$box->addContent(5);", nicht "$box->addContent($irgendwasFuerSelf, 5);".
        Oder auch "$box->showContent();", und nicht "$box->showContent($irgendwasFuerSelf);".
        Die Methode addContent() erwartet also zwei Argumente, erhält aber nur eins, und ist damit trotzdem zufrieden.
        Das ist etwas merkwürdig (daran sieht man auch, daß das $self merkwürdig, bzw. etwas Besonderes ist), aber so funktioniert das nunmal bei den Klassen.
        
        +2 replies
        
        Kuerbis
        
        2018-02-23 08:09
        
        User since
        2011-03-20
        947 Artikel
        BenutzerIn
        
        In Perl kann man dem Konstruktor Daten übergeben:
        
        Quote
        The constructor can also accept additional parameters that define the object. Let's write a real constructor for the File class we used earlier:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10
        
        package File; sub new { my $class = shift; my ( $path, $data ) = @_; my $self = bless { path => $path, data => $data, }, $class; return $self; }
        
        (https://perldoc.perl.org/perlobj.html)
        
        Für mich sieht es so aus, dass bless ein $self zurück gibt, wobei mir im Laufe der Diskussion aufgefallen ist, das ich in der Dokumention $self als Argument unterschlagen habe.
        
        hlubenow
        
        2018-02-23 17:10
        
        User since
        2009-02-22
        875 Artikel
        BenutzerIn
        
        2018-02-23T07:09:15 Kuerbis
        In Perl kann man dem Konstruktor Daten übergeben
        
        Ja. Das hat aber nichts direkt mit dem Thema zu tun.
        Sondern das wäre dann sowas:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
        
        #!/usr/bin/perl use warnings; use strict; package Box { sub new { my $classname = shift; my $content_at_beginning = shift; my $self = {content => $content_at_beginning}; return bless($self, $classname); } } my $box1 = Box->new(1); my $box2 = Box->new(5);
        
        Es geht dabei also darum, was man new() mitgibt. Die Postings oben bezogen sich dagegen auf die anderen Methoden als new() (den Konstruktor).
  - +5 replies
  - rosti
    
    2018-02-22 16:15
    User since
    2011-03-19
    3474 Artikel
    BenutzerIn
    
    Wenn das so ist, daß dieses Plugin eine eigene Package ist,
    
    Code (perl): (dl )
    
    package App::DBBrowser::DB::MyPlugin;
    
    dann würde ich dafür eine Konfiguration vorsehen die als INI z.B. mit Config::Tiny gelesen werden kann. Und die DB-Connection zu einem Attribut der Instanz machen, was bereits der Konstruktor erledigt.
    
    MfG
    Last edited: 2018-02-22 16:16:53 +0100 (CET)
    - +4 replies
    - Kuerbis
      
      2018-02-22 17:08
      
      User since
      2011-03-20
      947 Artikel
      BenutzerIn
      
      Die Informationen in $info sind nur ein Angebot, das Plugin könnte auch eine eigene Konfigurationsdatei benutzen.
      - +3 replies
      - rosti
        
        2018-02-24 10:25
        
        User since
        2011-03-19
        3474 Artikel
        BenutzerIn
        
        2018-02-22T16:08:28 Kuerbis
        Die Informationen in $info sind nur ein Angebot, das Plugin könnte auch eine eigene Konfigurationsdatei benutzen.
        
        Nun, ohne weitere Prüfungen würde ich das nicht so durch den Konstruktor reichen und mit dem Namen der Klasse segnen. Zum Filtern von Argumenten macht sich ein Hash ganz nützlich:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7
        
        sub new{ my $class = shift; my %cfg = ( name => '', ort => '', @_); }
        
        womit man auch sehr gut sehen kann, um welche Daten es da geht. Übernommen wird erst nach der Prüfung aber dann so:
        
        Code (perl): (dl )
        
        1 2 3 4
        
        bless{ name => $cfg{name}, ort => $cfg{ort} }, $class;
        
        damit man der Instanz nicht einfach so beliebige Eigenschaften unterjubeln kann. Statt einfacher Schlüsselnamen sind auch welche mit vorangestelltem Dash verbreitet die aus der UNIX-Welt entlehnt sind:
        
        Code (perl): (dl )
        
        1 2
        
        my $person = Person->new( -name => 'Otto', -ort => 'Hamburg' ) || die $@;
        
        Und das sieht auch ein kleinbischen besser aus, als nicht benötigte Argumente einfach so in den Skat zu drücken ;)
        
        +2 replies
        
        hlubenow
        
        2018-02-24 17:52
        
        User since
        2009-02-22
        875 Artikel
        BenutzerIn
        
        2018-02-24T09:25:16 rosti
        
        Code (perl): (dl )
        
        my $person = Person->new( -name => 'Otto', -ort => 'Hamburg' ) || die $@;
        
        Das deckt sich dann wieder mit dem, was ich so kenne.
        Das ist der Aufruf von außen. Wie man das Gegenstück innerhalb der Klasse umsetzt und auch Default-Werte setzt, wenn nichts für "-name" oder "-ort" angegeben wird, hatte ich hier dargestellt.
        
        Ich hatte das natürlich auch in irgendwelchen Dokumenten gefunden.
        
        Das ist ja auch die Syntax, die man von den meisten objektorientiert geschriebenen Modulen kennt, z.B. auch von Perl/Tk. Dazu dann von mir noch hier.
        Last edited: 2018-02-24 17:56:32 +0100 (CET)
        
        rosti
        
        2018-02-24 18:40
        
        User since
        2011-03-19
        3474 Artikel
        BenutzerIn
        
        Ja, die Vorbelegung ist manchmal ganz nützlich und geht auch so z.B.:
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        sub dump_and_die{ my $self = shift; my $ref = shift || $self; die Dumper $ref; }
        
        Oder die Umkehrung der Vorbelegung, also Leerstring oder undef setzen:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9
        
        sub new{ my $class = shift; my %cfg = ( -name => '', @_); croak "-name ist zwingend erforderlich!!!" unless $cfg{-name}; }
        
        MfG
- +15 replies
- Kuerbis
  
  2018-02-26 18:21
  User since
  2011-03-20
  947 Artikel
  BenutzerIn
  In der überarbeiteten Version der Plugin-API und -Dokumentation habe ich Anregungen von hier mit eingearbeitet. Dabei ist die Frage aufgekommen, wie ich Methoden benennen soll.
  Ist es schöner Methoden
  
  Code (perl): (dl )
  
  1 2
  
  databases() db_hanlde()
  
  zu nennen oder
  
  Code (perl): (dl )
  
  1 2
  
  get_databases get_db_handle
  
  Bei der Suche im Netz wurde oft mit "get_" empfohlen. In DBI hingegen heißen die Methoden
  
  Code (perl): (dl )
  
  1 2 3 4
  
  tables primary_key column_info ...
  - hlubenow
    
    2018-02-26 21:37
    
    User since
    2009-02-22
    875 Artikel
    BenutzerIn
    
    2018-02-26T17:21:34 Kuerbis
    Bei der Suche im Netz wurde oft mit "get_" empfohlen.
    
    Beim Schreiben von Klassen kam es bei mir automatisch vor, daß ich von einem Objekt einen bestimmten Wert wissen wollte. Dadurch lag es nahe, die zugehörige Methode "get_...()" zu nennen.
    
    Tatsächlich gibt es dafür aber Konventionen in der OOP-Theorie, z.B. Wikipedia-Erklärung dazu.
    Getter-Methoden dienen also zur Kapselung.
    Objekte sollen wie Maschinen sein, die einen Benutzer haben. Mein Beispiel war schonmal ein (mechanischer) Getränkeautomat. Der Benutzer braucht nicht zu wissen, wie der Automat funktioniert, dennoch kann er ihn benutzen.
    Dann würde er also sagen: "$automat->getGetraenk();" oder so, und dadurch eben irgendwie ein erfrischendes Getränk erhalten.
    Oder denk' an ein Tk-Entry-Feld: get() liefert den Text aus dem Feld als String, set() kann einen Text in das Feld setzen.
    Wenn Deine Methoden in dieser Art sind, wäre "get_...()" angemessen.
    
    Ich bin aber nicht sicher, ob meine Antwort (oder überhaupt meine OOP-Erläuterungen) einem Informatikprofessor genügen würden.
    Bei mir ist das nur Hobby.
    Last edited: 2018-02-26 21:43:11 +0100 (CET)
  - +2 replies
  - rosti
    
    2018-02-27 08:19
    User since
    2011-03-19
    3474 Artikel
    BenutzerIn
    
    Das DB Handle wird doch nur intern gebraucht, nehme ich mal an. Wozu das also über eine Methode nach draußen reichen?
    
    Davon ausgehend, könnte der Aufruf der Methode zur Herstellung der Sitzung so aussehen, also als private Methode mit einem vorangestelltem Unterstrich deklariert:
    
    Code (perl): (dl )
    
    $self->_dbh();
    
    Wobei der Name der DB nicht einmal übergeben werden muss wenn er bereits bei der Instanzerstellung aus der Konfiguration gelesen wurde -- so liegt der Name der DB intern in einem Attribut der Instanz.
    
    MfG
    - Kuerbis
      
      2018-02-27 18:03
      
      User since
      2011-03-20
      947 Artikel
      BenutzerIn
      
      Die get_db_hanlde Methode wird von der App genutzt, um sich mit verschiedenen Datenbanken verbinden zu können. Es gibt auch Situationen, in denen die App die Verbindung trennt um sich dann wieder neu zu verbinden.
  - +5 replies
  - Muffi
    
    2018-02-27 13:47
    User since
    2012-07-18
    1465 Artikel
    BenutzerIn
    
    Ich glaub da gibt's keine weltweit eindeutige Konvention über alle Programmiersprachen.
    Ich persönlich bin nicht der größte Freund von "get..."
    
    Ich seh die Zusatzinfo, die der get bringt in den meisten Fällen nicht.
    
    Code (perl): (dl )
    
    my $name = $user->first_name.' '.$user->last_name;
    
    Was daran nicht klar, bzw. welche Zusatzinfo bringt ein get?
    1 + 1 = 10
    - Linuxer
      
      2018-02-27 16:31
      
      User since
      2006-01-27
      3890 Artikel
      HausmeisterIn
      
      Allgemeine Konventionen wären mir da auch nicht bekannt. Je nach "Glaubensrichtung" eher Empfehlungen.
      Ich behaupte, dass ich auch oft auf diese Präfixe verzichte.
      
      Einen Vorteil sehe ich in der möglichen Eindeutigkeit.
      
      Gerade wenn man Methoden hat, von denen die einen lesen und setzen können und andere nur lesen, aber nicht setzen.
      
      Bei get_firstname() und set_firstname() ist leicht zu erkennen was sie jeweils tun.
      Bei firstname() nicht. Liest das nur? Kann das auch setzen?
      
      edit:
      Class::Accessor bietet z.B. die Möglichkeit, Damian Conways "Best Practices" zu berücksichtigen und die get_/set_-Präfixe einzusetzen. Aber sind halt "nur Empfehlungen". Am Ende hängt es vom persönlichen Geschmack ab, bzw. auf was man sich im Entwickler-Team geeinigt hat.
      Last edited: 2018-02-27 16:34:40 +0100 (CET)
      meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
      Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
    - rosti
      
      2018-02-27 17:07
      
      User since
      2011-03-19
      3474 Artikel
      BenutzerIn
      
      Schönes Beispiel ;)
      
      Btw., ich kenne einige CPAN Module, da werden bestimmte Eigenschaften per AUTOLOAD herausgegegben. D.h., die Instanz ruft einfach eine Methode auf und AUTOLOAD prüft, ob es eine Eigenschaft mit dem Namen der aufgerufenen Methode gibt. Warum sollte man da eine Eigenschaft 'get_name' nennen?
      
      Ich halte diese get_prefixe für ein Klischee und auf jeden Fall nicht für das was OOP ausmacht.
      
      MfG
    - +2 replies
    - hlubenow
      
      2018-02-27 20:04
      
      User since
      2009-02-22
      875 Artikel
      BenutzerIn
      
      2018-02-27T12:47:54 Muffi
      
      Code (perl): (dl )
      
      my $name = $user->first_name.' '.$user->last_name;
      
      Was [ist] daran nicht klar ... ?
      
      Also, das sieht ja nun so aus, als würdest Du auf die Attribute zugreifen, d.h. wie "$user->{first_name}". Daß das Methodenaufrufe sein sollen, bei denen dann auch noch die Funktionsklammern weggelassen wurden, dürfte die meisten Leute, die jetzt keine Perl-Spezialisten sind, verwirren.
      Da wäre ein "$user->getFirstName();" schon wesentlich deutlicher.
      Last edited: 2018-02-27 20:06:00 +0100 (CET)
      - clms
        
        2018-03-01 14:33
        
        User since
        2010-08-29
        373 Artikel
        BenutzerIn
        
        2018-02-27T19:04:49 hlubenow
        2018-02-27T12:47:54 Muffi
        
        Code (perl): (dl )
        
        my $name = $user->first_name.' '.$user->last_name;
        
        Was [ist] daran nicht klar ... ?
        
        Also, das sieht ja nun so aus, als würdest Du auf die Attribute zugreifen, d.h. wie "$user->{first_name}".
        
        Ja und? Du willst und machst (indirekt) genau das: lesend auf ein Attribut des Objekts zugreifen. Selbst wenn das Attribut als solches im Objekt nicht existiert und erst "on-the-fly" berechnet wird, ist das wegen der Objekt_Enkasulierung egal.
        
        Der einzige Unterschied zu einem "richtigen" Attribut ist, das Du das Konstrukt nicht als left-hand-side verwenden kannst. Aber das wird hier ja auch nicht gemacht.
        
        Ist natürlich Geschmackssache, aber ich mag diese Schreibweise recht gerne, insbesondere wenn ich auf Unterobjekte zugreife (z.B. Auto->Motor->Anlasser oder Server->ftp->put(file)).
        Das letzte Beispiel zeigt dann auch, dass ich dort, wo tatsächlich eine Aktion gemeint ist, ein Verb als Funktionsnamen verwende und die Klammern setze.
        
        Am Beispiel nicht zuerkennen ist dagegen die Funktionalität hinter ftp(). Oft generiere ich das FTP-Objekt erst beim ersten Aufruf von ftp() und öffne dann auch noch die Verbindung automatisch.
  - +6 replies
  - Kuerbis
    
    2018-02-27 18:11
    
    User since
    2011-03-20
    947 Artikel
    BenutzerIn
    
    Immer diese Entscheidungen. Mir kommt es ohne get_ ein bisschen weniger umständlich vor. Auch weil nicht direkt Daten von einem Objekt zurückgegeben werden, die Datenbankennamen werden irgendwie zusammengesucht und dann zurückgegeben.
    - +5 replies
    - MarkusH
      
      2018-02-27 19:31
      
      User since
      2012-04-08
      161 Artikel
      BenutzerIn
      
      Ich will jetzt doch auch meinen Senf dazu geben!
      Als Methodenname wird im allgemeinen empfohlen, Verben oder verbale Ausdrücke zu verwenden.
      Demnach ist
      
      Code (perl): (dl )
      
      sub getDbHandle{...}
      
      richtig und
      
      Code (perl): (dl )
      
      sub dbHandle{...}
      
      falsch!
      $q =~ /(bb|[^b]{2})/
      - +4 replies
      - hlubenow
        
        2018-02-27 20:07
        
        User since
        2009-02-22
        875 Artikel
        BenutzerIn
        
        2018-02-27T18:31:59 MarkusH
        Als Methodenname wird im allgemeinen empfohlen, Verben oder verbale Ausdrücke zu verwenden.
        
        Das macht ja auch Sinn, wenn man dabei an die (z.B. mechanische) Maschine denkt, die durch den Methodenaufruf etwas tun soll.
        
        +3 replies
        
        rosti
        
        2018-02-28 06:30
        
        User since
        2011-03-19
        3474 Artikel
        BenutzerIn
        
        2018-02-27T19:07:08 hlubenow
        2018-02-27T18:31:59 MarkusH
        Als Methodenname wird im allgemeinen empfohlen, Verben oder verbale Ausdrücke zu verwenden.
        
        Das macht ja auch Sinn, wenn man dabei an die (z.B. mechanische) Maschine denkt, die durch den Methodenaufruf etwas tun soll.
        
        Logisch, Maschinen wissen ja auch was Verben sind. Genauso wie XML, CSV maschinenlesbar ist... Gibt der Maschine eine Chance dem Code zu verstehen ;)
        
        .
        
        +2 replies
        
        hlubenow
        
        2018-02-28 10:31
        
        User since
        2009-02-22
        875 Artikel
        BenutzerIn
        
        2018-02-28T05:30:29 rosti
        Logisch, Maschinen wissen ja auch was Verben sind. Genauso wie XML, CSV maschinenlesbar ist... Gibt der Maschine eine Chance dem Code zu verstehen ;).
        
        Es geht darum, daß man ausdrücken will, daß man einer Maschine eine Anweisung gibt, etwas Bestimmtes zu tun:
        Z.B.
        
        Code: (dl )
        
        Getränkeautomat->GibMirEinGetränk();
        
        oder
        
        Code: (dl )
        
        Auto->FahreMichNachBerlin();
        
        oder
        
        Code: (dl )
        
        T_800->BeschützeMichVorDemT_1000(Pumpgun);
        
        ;)
        Last edited: 2018-02-28 10:34:02 +0100 (CET)
        
        rosti
        
        2018-02-28 10:47
        
        User since
        2011-03-19
        3474 Artikel
        BenutzerIn
        
        Verstehe ;)
        
        Aber wenn mir dann die Kiste trotz meiner Höflichkeit mit einer nichtssagenden Exception antwortet, finde ich das schon ziemlich ungerecht ;)
        
        MfG
        Last edited: 2018-02-28 13:42:19 +0100 (CET)

View all threads created 2018-02-22 08:19.