Wildcard in Abfrage ... oder so ähnlich ;)

[heinetz]

Hallo Forum,

in meinem assoziativen php-array '$office_A' befinden sich mehrere Keys (?). Z.B gibt es:

$office_A['title'],
$office_A['name'],
 usw.

Unter Umständen gibt es ausserdem:
$office_A['postanschrift_street'],
$office_A['postanschrift_building'],
usw.

Ich möchte abfragen, ob es Keys mit dem Prefix 'postanschrift_'
gibt. Das würde ich mit meienm Kenntnisstand so machen:

if (
$office_A['postanschrift_street'] ||
$office_A['postanschrift_building']
) $test = true;

Wie kann man elegant nach Keys mit dem Prefix 'postanschrift_'
abfragen ?

danke fuer Tipps und

beste gruesse,
heinetz

[Edgar Ehritt]

Tach Heinetz,

durchlaufe das array mit foreach und vergleiche dann Teilzeichenkennten mittels substr im Anweisungsblock der Schleife!

Gruß aus Berlin!
eddi

[Tom]

Hello,

$office_A['postanschrift_street'] ||
$office_A['postanschrift_building']
) $test = true;

Wie kann man elegant nach Keys mit dem Prefix 'postanschrift_'
abfragen ?

eleganter wäre es, das Array gleich zu untergliedern

$office_A['postanschrift']['street']
 $office_A['postanschrift']['building']

Sonst solltest Du dir zur Vermeidung irgendwelcher Seiteneffekte eine eigene Funktion schreiben, in der dur die Arrays iterierst.

foreach($office_A as $key => $value)
   {
       if (strpos($key, $prefix)===0) laut_aufschrei();
   }

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sympathisant]

Hai,

eleganter wäre es, das Array gleich zu untergliedern

..oder gleich mit Objekten zu arbeiten. Somit spart man sich das ewige Nachschauen, welche Keys ein Array denn wohlmoeglich haben koennte.

  
class Office {  
  protected $name;  
  protected $Address; // reference object  
  
  public function GetName() {  
    return $this->name;  
  }  
  
  public function GetAddress() {  
    return $this->Address;  
  }  
  
  // [..]  
}  
  
class Address {  
  protected $street;  
  
  public function GetStreet() {  
    return $this->street;  
  }  
}  
  
// Aufruf  
if( isset( $myOffice->GetAddress() )  
  echo $myOffice->GetAddress()->GetStreet();  

MfG,
Sympathisant

[Edgar Ehritt]

Hallo Sympathisant,

..oder gleich mit Objekten zu arbeiten.

das ist für den ersichtlichen Einsatz fast schon unschlagbarer code blow up.

Somit spart man sich das ewige Nachschauen, welche Keys ein Array denn wohlmoeglich haben koennte.
if( isset( $myOffice->GetAddress() ){}

Wie bitte?

Gruß aus Berlin!
eddi

[Sympathisant]

Hai eddi,

das ist für den ersichtlichen Einsatz fast schon unschlagbarer code blow up.

Das sehe ich gar nicht so.
In der Praxis werden Applikationen kontinuierlich erweitert. Und man sollte sich nicht bereits am Anfang der Moeglichkeit entziehen, zukuenftige Anforderungen oder Aenderungen mit dem geringsten Aufwand implementieren zu koennen.

Der vom OP gepostete Code sieht sehr danach aus, als kaemen die Daten aus der Datenbank.
Zudem sieht es so aus, als handle es sich um Kundendaten (er nannte eine Variable "Office").
Und da Kundendaten in einer Applikation selten an einer einzigen Stelle referenziert werden, koenne wir davon ausgehen, dass der Zugriff auf das Array noch an weiteren Stellen im Code erfolgen wird.

Und Zugriffe auf dynamische Datenstrukturen mittels assoziativer Arrays sind fehleranfaellig.
Hierfuer gibt es viele Gruende.

Einer davon ist, dass ein potentieller Fehler erst zur Laufzeit auffallen respektive auftreten wird. Zur Compilezeit steht nicht fest, ob der angegebene Key in dem Array ueberhaupt existiert.

Ein weiterer Grund ist die allgemeine Reduzierung des Fehlerpotentials. Denn bei der Verwendung von Strings als Identifier koennen ganz leicht Rechtschreibfehler auftreten.

Dann waere da noch die Wartbarkeit. Angenommen, der Key aendert sich aus bestimmten Gruenden. Dann muesste ein projektweites Refactoring stattfinden. Und das nur, weil aus dem Wort "strasse" das wort "strasse_1" geworden ist. Im Falle eines Datenobjektes muessten wir nur eine einzige Stelle im Code anpassen (und zwar genau dort, wo die Daten der Datenbank auf das Datenobjekt gemapped werden*), denn saemtliche Zugriffe laufen ueber einen wohl definierten Methodeaufruf ($Customer->GetStrasse()).

Dann ist da noch das Thema "Einarbeitung". Angenommen, es stoszen zu dem Team weitere Entwickler hinzu:
Arbeitet man sauber und durchgaengig mit Datenobjekten (und Klassen im Allgemeinen), so ist fuer den Entwickler die Einarbeitung um ein erhebliches leichter. Bleiben wir bei dem Beispiel des OP: Woher soll ein Entwickler wissen, welche Keys fuer den Array existieren? Moechte er das in Erfahrung bringen, so muss er sich auf die Suche begeben.
Nutzt man statt dessen jedoch Datenobjekte, so bedarf es nur einen Blick in die entsprechende Klasse (arbeitet man mit guten IDEs braucht man nicht einmal das zu tun, da sie einem bereits die Methoden des Objektes anzeigen).
Ein Unterpunkt hierzu ist die Moeglichkeit (korrekt kommentierte Klassen vorausgesetzt), sich mit einfachen Mitteln sogar eine API der Anwendung erstellen zu lassen.

In der Praxis gewichten die Resultate der oben aufgelisteten Punkte hoeher, als die Befuerchtung des "code blow ups".
Zudem sehe ich durch die Verwendung von Datenobjekten nicht die Tatsache, dass der Code "aufgeblaeht" wird. Im Gegenteil, sie fuehrt sogar zu mehr Uebersicht und Struktur.

if( isset( $myOffice->GetAddress() ){}
Wie bitte?

War die Kurzform - es sollte nur der Veranschaulichung dienen.
Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

* Im Falle von PDO braucht man das Mapping nicht einmal selbst vorzunehmen. Siehe hierzu http://de.php.net/manual/en/pdostatement.fetchobject.php

MfG,
Sympathisant

[Tom]

Hello,

if( isset( $myOffice->GetAddress() ){}
Wie bitte?
War die Kurzform - es sollte nur der Veranschaulichung dienen.

Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

Eine "Methode" hat nur dann einen Rückgabewert, wenn sie auch als "Funktion" definiert wurde und nicht nur als "Prozedur", um mal diese gutan alten Museumsbegriffe zu bemühen.

Die Deklaration sieht in PHP ja leider immer gleich aus, zumal man sie gar nicht mehr aktiv wahr nimmt, da auch Methoden implizit deklariert werden, also durch ihre Definition.

Es muss also einfach ein Rückgabewert mittels 'return' erzeugt werden.

Bevor Du OOP benutzt, solltest Du vielleicht erst mal einen Grundkurs in klassischer Programmierung machen, sonst passiert nämlich genau das, was ich hier immer proklamiere: OOP wird nur benutzt, weil es chic ist und aus reinem Selbstzweck...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sympathisant]

Hai Tom,

na Himmel, Arsch und Zwirn.
Jetzt kommst du wieder mit so was um die Ecke.

Dass du dich jeglicher Diskussionsansprueche entbehrst,
sollte dir ja hoffentlich noch bewusst sein.

MfG,
Sympathisant

[Tom]

Hello,

*rotfl*

na Himmel, Arsch und Zwirn.
Jetzt kommst du wieder mit so was um die Ecke.

Dass du dich jeglicher Diskussionsansprueche entbehrst,
sollte dir ja hoffentlich noch bewusst sein.

Eine Anklage ist noch lange kein Beweis. Da halte ich es mit Gallileo. Die Erde ist keine Scheibe, auch wenn es die Mondlandung nicht gegeben hat :-))

Nur wer das Ganze kennt, kann im Detail entscheiden!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Edgar Ehritt]

Hallo,

Hai eddi,

das ist für den ersichtlichen Einsatz fast schon unschlagbarer code blow up.
Das sehe ich gar nicht so.
In der Praxis werden Applikationen kontinuierlich erweitert. Und man sollte sich nicht bereits am Anfang der Moeglichkeit entziehen, zukuenftige Anforderungen oder Aenderungen mit dem geringsten Aufwand implementieren zu koennen. Der vom OP gepostete Code sieht sehr danach aus, als kaemen die Daten aus der Datenbank.
Zudem sieht es so aus, als handle es sich um Kundendaten (er nannte eine Variable "Office").
Und da Kundendaten in einer Applikation selten an einer einzigen Stelle referenziert werden, koenne wir davon ausgehen, dass der Zugriff auf das Array noch an weiteren Stellen im Code erfolgen wird.

Schlichtweg ist der Gebrauch einer Datenbank eben sowenig Argument der Vorteile von Objekten wie auch Mehrfachzugriffe.

Und Zugriffe auf dynamische Datenstrukturen mittels assoziativer Arrays sind fehleranfaellig. Hierfuer gibt es viele Gruende. Einer davon ist, dass ein potentieller Fehler erst zur Laufzeit auffallen respektive auftreten wird. Zur Compilezeit steht nicht fest, ob der angegebene Key in dem Array ueberhaupt existiert. Ein weiterer Grund ist die allgemeine Reduzierung des Fehlerpotentials. Denn bei der Verwendung von Strings als Identifier koennen ganz leicht Rechtschreibfehler auftreten.

Hier notierst Du doch auch isset(), warum also soll isset($obj->return_val()) weniger fehleranfälliger als isset($array['key'])) sein? Was verleitet im Falle genutzter Objekte weniger zu Schreibfehlern bei Methodennamen?

Dann waere da noch die Wartbarkeit. Angenommen, der Key aendert sich aus bestimmten Gruenden. Dann muesste ein projektweites Refactoring stattfinden. Und das nur, weil aus dem Wort "strasse" das wort "strasse_1" geworden ist. Im Falle eines Datenobjektes muessten wir nur eine einzige Stelle im Code anpassen (und zwar genau dort, wo die Daten der Datenbank auf das Datenobjekt gemapped werden*), denn saemtliche Zugriffe laufen ueber einen wohl definierten Methodeaufruf ($Customer->GetStrasse()).

Was ist an $array['key'] schlechter wartbar $obj->$strin_name()? Würde sich Sting 'key' verändern, ist dies nicht adäquat zu Veränderungen von Objekteigenschaften sondern zu Methodennamen. Du vergleichst schlichtweg Äpfel mit Birnen. Passend wäre ein Vergleich der Erweiterung vom Datenfeld um ein Schlüssel-Werte-Paar zur Erweiterung eines Objekts.
 Aber sei's drum: Bei Umbenennungen innerhalb des Codes, wie die angeführte Änderung von 'key' in $array['key'], lässt man aus Gründen von Schreibfehlern eine Tokenizerapplikation kurz das Projekt parsen und anpassen.

Dann ist da noch das Thema "Einarbeitung". Angenommen, es stoszen zu dem Team weitere Entwickler hinzu:

Oben versuchst Du noch am Beispiel Argumente aufzustellen, während Du Dich jetzt vollends davon lossagst, um Objekten den zumindest aus Deinen Argumenten nicht ersichtlichen Vorteile zuzusprechen.

Arbeitet man sauber und durchgaengig mit Datenobjekten (und Klassen im Allgemeinen), so ist fuer den Entwickler die Einarbeitung um ein erhebliches leichter.

Das ist eine unbegründete Parole.

Bleiben wir bei dem Beispiel des OP: Woher soll ein Entwickler wissen, welche Keys fuer den Array existieren?

print_r($array); - was die Laufzeit anbelangt; und ansonsten ist die ordnungsgemäße Kommentierung seines Codes einem sich selbst erklärenden Interface absolut ebenbürtig, was die Einarbeitung betrifft. Das Argument der blow ups lastet dann aber noch gewichtiger.

Moechte er das in Erfahrung bringen, so muss er sich auf die Suche begeben.
Nutzt man statt dessen jedoch Datenobjekte, so bedarf es nur einen Blick in die entsprechende Klasse (arbeitet man mit guten IDEs braucht man nicht einmal das zu tun, da sie einem bereits die Methoden des Objektes anzeigen).

Ähm... Aua!
Eine Integrierte Entwicklungsumgebung, die klassen besser visoalisiert als Datenfelder, würde ich nicht als "gut" bezeichnen.

Ein Unterpunkt hierzu ist die Moeglichkeit (korrekt kommentierte Klassen vorausgesetzt), sich mit einfachen Mitteln sogar eine API der Anwendung erstellen zu lassen.
In der Praxis gewichten die Resultate der oben aufgelisteten Punkte hoeher, als die Befuerchtung des "code blow ups".
Zudem sehe ich durch die Verwendung von Datenobjekten nicht die Tatsache, dass der Code "aufgeblaeht" wird. Im Gegenteil, sie fuehrt sogar zu mehr Uebersicht und Struktur.

Wenn man sowieso schon auf dem Auge für KISS blind ist, reicht das sicher auch als Argument.
 Ich weis nicht, wie der PHP-Programmierer von heute stereotypisch aussieht. Sitzt der von einem Appel und braucht der alles bunt und schön, oder sitzt der vor einer Konsole mit vim und kann auch mit var_dump() oder eigens geschriebene Klasseniterationen umgehen?

Somit spart man sich das ewige Nachschauen, welche Keys ein Array denn wohlmoeglich haben koennte.
if( isset( $myOffice->GetAddress() ){}
Wie bitte?

Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

Diese Variable muss dennoch überprüft werden, ob sie Inhalt enthält. (Punkt)
Du weigerst Dich Dein eigens ins Spiel gebrachte Argument ("Somit spart man sich das ewige Nachschauen, welche Keys ein Array denn wohlmoeglich haben koennte.") mit Deinem kurzformulierten Beispielcode als unvereinbar in Verbindung zu bringen. Das ist keine Diskussionsgrundlage!

Entschuldige bitte aber dem seit mehreren Jahren sich hier in diesem Forum breitgemachten Predigen von unreflektiert übernommenen Lehrsätzen, muss IMHO wieder mehr Objektivität - nicht Objektorientierung - entgegengestellt werden.

Gruß aus Berlin!
eddi

[Sympathisant]

Hai Eddi,

was ist denn mit dir passiert? Ich glaube du moechtest mich unbedingt falsch verstehen.

Schlichtweg ist der Gebrauch einer Datenbank eben sowenig Argument der Vorteile von Objekten wie auch Mehrfachzugriffe.

Ich habe an keiner Stelle gesagt, dass eine Datenbank ein Argument fuer Datenobjekte sei. Ich habe nur geschlussfolgert, dass es sich um Daten aus der Datenbank handelt. Ob die Daten vom Himmel fallen oder gleich direkt aus dem Nirvana stammen, ist gaenzlich egal.

Hier notierst Du doch auch isset(), warum also soll isset($obj->return_val()) weniger fehleranfälliger als isset($array['key'])) sein? Was verleitet im Falle genutzter Objekte weniger zu Schreibfehlern bei Methodennamen?

Na, die IDE natuerlich.

Arbeitet man sauber und durchgaengig mit Datenobjekten (und Klassen im Allgemeinen), so ist fuer den Entwickler die Einarbeitung um ein erhebliches leichter.
Das ist eine unbegründete Parole.

Dito.

Bleiben wir bei dem Beispiel des OP: Woher soll ein Entwickler wissen, welche Keys fuer den Array existieren?
print_r($array); - was die Laufzeit anbelangt;

Na super. Und wenn Du vorher ueber etliche Seiten/Formulare/etc. navigieren musst, um zu der entsprechenden Anzeige zu gelangen? Das ziehst du tatsaechlich dem Blick in der APi / dem Interface / dem Object vor?

Ähm... Aua!
Eine Integrierte Entwicklungsumgebung, die klassen besser visoalisiert als Datenfelder, würde ich nicht als "gut" bezeichnen.

Deine Missinterpretationen sind ja fast schon grob fahrlaessig!

Warum redest Du denn jetzt von Klassenvisualisierung? Um warum zum Henker ist eine IDE, die anhand des Objektes die zugehoerigen Methoden auflistet, nicht der Bezeichnung "gut" wert? Das ist stinknormale Praxis.

Wenn man sowieso schon auf dem Auge für KISS blind ist, reicht das sicher auch als Argument.
Ich weis nicht, wie der PHP-Programmierer von heute stereotypisch aussieht. Sitzt der von einem Appel und braucht der alles bunt und schön, oder sitzt der vor einer Konsole mit vim und kann auch mit var_dump() oder eigens geschriebene Klasseniterationen umgehen?

Jetzt redest du auf einmal von "bunt" und "schoen" und "Apple", und betrachtest das ganz wohlmoeglich noch als Diskussionsgrundlage?
Und, nichts ist schlimmer als sich mit etlichen "echo"- oder "var_dump"-Ausgaben rumzuschlagen und das ganze dann als Debuggen zu bezeichnen.

Das ist keine Diskussionsgrundlage!

S.o.

Entschuldige bitte aber dem seit mehreren Jahren sich hier in diesem Forum breitgemachten Predigen von unreflektiert übernommenen Lehrsätzen, muss IMHO wieder mehr Objektivität - nicht Objektorientierung - entgegengestellt werden.

1. DAS soll die Entschuldigung dafuer sein, dass du mich so anfaehrst?
2. Bereits ein paar Woerter nach der Entschuldigung wirfst du mir vor, dass ich unreflektiert Lehrsaetze übernehmen wuerde. Also eine direktes Dementi.

Auf solch Entschuldigungen kann ich eindeutig verzichten!
Und darauf, als Ventil irgendwelcher persoenlicher Probleme deinerseits zu fungieren, die mich nicht mal interessieren, getrost auch!

MfG,
Sympathisant

[Edgar Ehritt]

Re:

was ist denn mit dir passiert? Ich glaube du moechtest mich unbedingt falsch verstehen.

Verstehst Du selbst Deine Argumentation nicht mehr?

das ist für den ersichtlichen Einsatz fast schon unschlagbarer code blow up.

***************************************

Das sehe ich gar nicht so. ...

***************************************

Der vom OP gepostete Code sieht sehr danach aus, als kaemen die Daten aus der Datenbank. [ - und im weiteren referierst Du über Mehrfachzugriffe und dessen Fehlerpotential]

Schlichtweg ist der Gebrauch einer Datenbank eben sowenig Argument der Vorteile von Objekten wie auch Mehrfachzugriffe.
Ich habe an keiner Stelle gesagt, dass eine Datenbank ein Argument fuer Datenobjekte sei. Ich habe nur geschlussfolgert, dass es sich um Daten aus der Datenbank handelt. Ob die Daten vom Himmel fallen oder gleich direkt aus dem Nirvana stammen, ist gaenzlich egal.

Warum hast Du es dann als Argument angefügt?

Hier notierst Du doch auch isset(), warum also soll isset($obj->return_val()) weniger fehleranfälliger als isset($array['key'])) sein? Was verleitet im Falle genutzter Objekte weniger zu Schreibfehlern bei Methodennamen?
Na, die IDE natuerlich.

Bereits ein paar Woerter nach der Entschuldigung wirfst du mir vor, dass ich unreflektiert Lehrsaetze übernehmen wuerde.

Du ziehst Produktionsmittel, die bei jedem unterschiedlich aussehen werden, für die Entwicklung von code als Argument heran. Das dies erkennbar den code in seiner Qualität ändert, lässt Du völlig außer acht. Ja, ich bezeichne sowas als unreflektiert.

Und im Übrigen: Beantworte bitte die Fragen!

Und darauf, als Ventil irgendwelcher persoenlicher Probleme deinerseits zu fungieren, die mich nicht mal interessieren, getrost auch!

Was ich selber denk und tu', trau ich andren Menschen zu?

Gruß aus Berlin!
eddi

[dedlfix]

Hi!

if( isset( $myOffice->GetAddress() ){}
Wie bitte?
War die Kurzform - es sollte nur der Veranschaulichung dienen.
Da PHP nicht faehig ist, den Rueckgabewert einer Methode direkt zu verwenden, muss man den Wert vorher natuerlich einer Variablen zuweisen.

Diese Aussage ist falsch. Rückgabewerte einer Funktion können seit PHP 5 sehr wohl direkt verwendet werden, wenn du damit meinst, dass man auf die Methoden oder Eigenschaften eines zurückgegebenen Objekts zugreifen kann - so wie es deine nächste nicht mehr zitierte Zeile zeigt.

Aber: Die Funktion isset() prüft auf das Vorhandensein einer Variablen, weshalb sie eine Variable erwartet. Etwas anderes zu übergeben, erzeugt einen Parse Error. Wenn deine Variable OfficeInstanz->$Address nicht gesetzt ist, so liefert ein Lesezugriff null zurück. Außerdem gibt es eine Notice, was immer ein Zeichen für eine Schludrigkeit ist. Dieses null gibt deine Getter-Methode zurück. Legtest du es in einer Variable ab, so sollte man meinen, durch den Schreibzugriff existiere diese Variable. Das macht sie auch in der Tat, nur PHP meint beim isset(), dass eine existierende Variable mit Inhalt null nicht existiert. Auf dieses Verhalten PHPs sollte man nicht bauen, finde ich, weil es zu sehr verwirrt. Man setzt eine Variable und fragt im nächsten Moment, ob sie existiert, liest sich so, als traue man PHP beim Variablenerzeugen nicht übern Weg. Erst wenn man diese isset()-Ausnahme kennt, wird einem das Verhalten klar. Schöner wird es dadurch aber nicht.

Lo!

[Sympathisant]

Hai Dedlfix,

Aber: Die Funktion isset() prüft [..]

Eine gute Erklaerung. Danke.

MfG,
Sympathisant

[heinetz]

hello,

was mir an dem Forum hier so gut gefällt, ist dass man mit einer
einfachen Frage Grundsatzdiskussionen lostritt ;)

schönen Dank,
heinetz

[Edgar Ehritt]

Re:

was mir an dem Forum hier so gut gefällt, ist dass man mit einer
einfachen Frage Grundsatzdiskussionen lostritt ;)

An eine produktionsmittelgebunden (möglicherweise auch noch der Zertifikatsabzocke anheimgefallenen) Abhängigkeit, und der daraus resultierenden Befürwortung von OOP, ist nur auf menschlicher Ebene grundsätzlich.

Gruß aus Berlin!
eddi