Perfektes PHPFatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM (16.5.2012, 17:19 UTC)

Diese Fehlermeldung gehört wohl zu den unverständlichsten Fehlermeldungen überhaupt. Um sie zu verstehen muss man erst einmal wissen, was mit T_PAAMAYIM_NEKUDOTAYIM gemeint ist. Das T_ steht für Token, also eines der “Bausteine”, in das der php-Parser den Quellcode unterteilt bevor er ihn ausführt. Und “Paamayim Nekudotayim” ist hebräisch für Doppel-Doppelpunkt. Die Fehlermeldung weist also einfach darauf hin, dass ein :: unerwartet aufgetreten ist.

Was sind die Ursachen und die Lösungen dafür?

1. Falscher Code:

$str = Ätsch;

Durch das & betrachtet php Auml als eine Referenz auf eine Klasse, auf die der Aufruf einer Methode folgen müsste: $str = Ä::tsch();. Vermutlich hat der Programmierer im obigen Beispiel aber eine einfache String-Zuweisung gemeint:

$str = 'Ätsch;';

2. Statischer Aufruf von nicht-statischen Methoden

class foo {
    public function bar() {
        echo 'bar()';
    }
}
foo::bar();

Auch dies führt zur oben genannten Fehlermeldung, jedoch nur in Versionen vor 5.3. php ab Version 5.3 gibt endlich eine hilfreichere Fehlermeldung aus: Non-static method foo::bar() should not be called statically. Aus ihr geht hervor, dass versucht wurde, die nicht-statische Methode bar() statisch (::-Operator) zu verwenden.
Abhilfe: entweder die Methode statisch machen:

static public function bar()

oder ein Objekt der Klasse instanziieren und die Methode aufrufen:

$fooObj = new foo;
$fooObj->bar();

3. Statischer Aufruf einer Methode einer dynamisch benannten Klasse

Ab Version 5.3 ist es möglich, beim (statischen) Aufruf einer Methode den  Klassennamen dynamisch, also mittels einer Variable anzugeben: 

$baz = 'foo';
$baz::bar();

Versionen vor 5.3 schmeißen auch in diesem Fall die eine T_PAAMAYIM_NEKUDOTAYIM-Fehlermeldung (hier natürlich expected T_PAAMAYIM_NEKUDOTAYIM anstatt unexpected).
Abhilfe schafft hier call_user_func:

call_user_func(array($baz, 'bar'), $optionale_parameter);

oder ab php 5.2.3

call_user_func($baz.'::bar', $optionale_parameter);

Link
Punktuelles im WebElefanten auf Java: Der Elefant ist gelandet! (16.5.2012, 07:00 UTC)
Steigen wir ohne große Worte direkt ein um zügig die notwendigen, aber vielleicht weniger interessanten Grundlagen für ein erstes “Hallo Welt” zu schaffen: Die Installation und Konfiguration der Laufzeitumgebungen von PHP und Java.
Wir konzentrieren uns dabei auf die Ausführung auf der Kommandozeile, komplexere Aspekte wie Webserver, Webseiten oder gar Applikationsserver lassen wir vorerst außer acht.
So richtig retro eben.
Weitere Informationen »
Link
Punktuelles im WebElefanten auf Java? (15.5.2012, 15:22 UTC)
Wussten Sie, dass es heutzutage nur noch wenige Elefanten auf Java gibt? Der Elefant ist nämlich nicht nur das Maskottchen von PHP und Java gibt es auch nicht nur als Programmiersprache. Aber zurück zum eigentlichen Thema.

Was kann man als PHP-Entwickler lernen?

Die Frage was man als PHP-Entwickler lernen soll (oder kann) um sich weiter zu entwickeln ist vermutlich schon hundertfach gestellt worden? Und so wie diese Frage unzählige male gestellt wurde, so unzählig sind auch die möglichen Antworten.

Meine persönliche Empfehlung ist es Java zu lernen. Abgesehen davon, dass diese Empfehlung genauso kritikwürdig und hilfreich ist wie jede andere Empfehlung auch, habe ich zumindest ein paar Gründe parat.
Weitere Informationen »
Link
PHP Gangsta - Der PHP Blog mit Prax ...Ticket für die Developer Conference 2012 in Hamburg zu gewinnen! (15.5.2012, 08:02 UTC)

Am 8. und 9. September 2012 findet die jährliche Developer Conference in Hamburg statt, und ich kann ein Ticket an euch verquizzen!

Was müßt ihr dafür tun? Beantwortet einfach die folgenden drei kurzen Fragen bis zum 30.05.2012 23:59:

=========================================

DevConQuiz

Name *
E-Mail-Adresse *

=========================================

Jeder darf natürlich nur einmal teilnehmen.

Der Gewinner wird dann hier im Blog veröffentlicht und bekommt auch eine E-Mail mit dem Amiando-Aktionscode.

Aktuell gilt der Early-Bird-Preis (25% Ersparnis!) bis Ende Juni. Für Interessierte gibt es auf der Webseite der Konferenz auch Bilder, Informationen der Vorträge sowie des Rahmenprogramms des letzten Jahres. Einige Speakerslots werden noch freigehalten, bei Interesse könnt ihr einfach die Orga anschreiben.

Vielen Dank an Tarek und das Orga-Team für die Bereitstellung des Preises! Und nun viel Glück bei der Teilnahme!



Keine ähnlichen Artikel.

Link
PHP UG Munich in München - PHPJobangebot München wg. Facebook-Anwendungen (11.5.2012, 13:00 UTC)

Die social sweethearts GmbH entwickelt und betreibt Facebook-Anwendungen mit mehr als 18 Millionen unique User weltweit. Für das Büro in München wird ab sofort ein PHP/MySQL-Entwickler (m/w) gesucht.

Alle Infos gibt es unter socialsweethearts


"Jobangebot München wg. Facebook-Anwendungen" vollständig lesen
Link
PHP Gangsta - Der PHP Blog mit Prax ...Die Reise des großen ElePHPanten (10.5.2012, 07:13 UTC)

Der letzte große ElePHPant möchte auf große Weltreise gehen! Die Frage ist: wohin möchte er? Schöne Städte und Dörfer hier in Deutschland besuchen, aber vielleicht auch in ganz Europa rumtouren, mit ganz viel Glück auf andere Kontinente?

Soll der ElePHPant zu dir kommen? Es gibt nur 3 Bedingungen die es zu erfüllen gibt:

  1. Er möchte seine Route hier veröffentlichen, und an jedem Ort Fotos machen. Jede Station muss mindestens 30 Kilometer auseinander liegen, er möchte ja möglichst viel sehen! Dann können wir eine Karte erstellen und Fotos (und vielleicht auch Videos!?) hier veröffentlichen und zu jedem Zeitpunkt sicherstellen wo es ihm gut geht.
  2. Er möchte die Reise so sicher wie möglich erleben, sprich per Paketdienst versichert von einem Ort zum nächsten reisen.
  3. Er möchte nicht länger als 14 Tage an einem Ort sein, und währenddessen viel erleben. Fotos von besonderen Orten mitnehmen, in Firmen reinschnuppern, im Auto vorne sitzen, aber auch relaxt auf der Couch liegen, und dann weiterreisen.

Nach 15 besuchten Orten möchte er wieder zuhause sein und sich von der Reise erholen. Währenddessen kann er euch dabei helfen Bugs zu finden, euch zur PHP-Usergroup begleiten, ihr könnt ihm Probleme erzählen an denen ihr nagt, und ihn mitnehmen wo auch immer ihr interessante Dinge erlebt.

Vincent Pontier hat den ElePHPanten entworfen und beschreibt ihn so:

Yet, I’ll have a word of caution: don’t kid yourself, this is not a toy! This is first and foremost a special partner for every PHP coder. Trouble with sessions? a bug in a class? a crashed method? Don’t worry! Just tell your elePHPant the problem, and he will give your the solution (and if the solution is not worth it, you may also throw him on the walls. And with the elePHPant with you, at home or at large, you’ll be stealing the show!

Also, zu wem soll er als erstes reisen? Meldet euch einfach in den Kommentaren bis zum nächsten Donnerstag (17.05.2012). Aber beachtet bitte dass ihr ihn auf eigene Kosten (ca. 6,90 Euro) nach 2 Wochen weiterschicken müßt an einen anderen Entwickler eurer Wahl.

Hier noch 2 aktuelle Fotos vom großen ElePHPanten:



Ähnliche Artikel:

  1. ElePHPanten zu Weihnachten?
  2. Töröö! Die ElePHPanten sind wieder da!
  3. ElePHPanten zu Weihnachten und Mayflower Adventskalender
Link
Software-Entwickler Bloginclude oder require? (8.5.2012, 20:55 UTC)
Was soll der PHP-Entwickler benutzen, include oder require bzw. include_once oder require_once?
Und wo liegt da eigentlich der Unterschied?

Die Frage kommt oft, deshalb an dieser Stelle mal ganz klipp und klar und kurz:

require bzw. require_once benutzen, denn: Sowohl include wie auch require binden eine Datei ein, aber, sollte ein Fehler in der includierten Dateie sein, so bricht require mit einem E_COMPILE_ERROR ab, während include fröhlich mit einer WARNING weitermacht.

Im Sinne der Vermeidung von code-smells fällt eure Wahl also auf require bzw. require_once.
Link
PHP Gangsta - Der PHP Blog mit Prax ...Kryptische Fehlermeldungen in PHP (8.5.2012, 08:03 UTC)

Mit den Jahren der Programmierung stößt man unwiderruflich auch auf komische Fehlermeldungen in PHP, die auch nach dem 3. Mal lesen unverständlich sind und die Fehlerquelle unklar bleibt. Hier möchte ich einige Fehlermeldungen auflisten an die ich mich erinnern kann, und auch kurz notieren wann und wieso sie auftreten.

Ich nehme mich da selbst nicht aus, in meinen Applikationen sind die Fehlermeldungen auch nicht immer sehr aussagekräftig, vor allem wenn sie sehr selten oder “nie” auftreten sollten, von daher wird hier niemand an den Pranger gestellt, es soll nur helfen einige interessante Meldungen zu verstehen:

  1. Fatal error: Exception thrown without a stack frame in Unknown on line 0
    Mein Favorit wenn es darum ging an Fehlermeldungen zu verzweifeln. Die Fehlermeldung sagt also dass PHP in der Datei Unknown in Zeile 0 keinen Stack-Frame erstellen konnte als eine Exception geworfen wurde. Prima!
    Der Fehler trat auf wenn PHP noch nicht richtig, bzw. nicht mehr richtig läuft oder sich in einigen magischen Methoden befindet. PHP konnte anscheinend nicht feststellen wo im Programmfluss es gerade steckte.
    Untersuchen sollte man die Stellen wo in einem Konstruktor, einem Destruktor oder einem Exception-/Error-Handler eine Exception geworfen wird. Entweder man entfernt die Exceptions und löst das Problem anders, oder fügt dort jeweils einen try-catch-Block hinzu, sodass die Exception nicht geworfen wird.
    Ich habe diese 3 Möglichkeiten gerade nochmal versucht nachzustellen mit PHP 5.3.8, aber mittlerweile kommen da aussagekräftige Fehlermeldungen mit Datei- und Zeilenangaben. Die kryptische Fehlermeldung scheint also irgendwann (vielleicht zum 5.3.0 Release?) ersetzt worden zu sein. Schade ;-)
  2. Fatal error: Can’t use function return value in write context
    Dieser Fehler ist auch etwas schwer zu verstehen wenn man noch nicht jahrelang programmiert, aber kann nur in 2 mir bekannten Fällen auftreten, und zwar bei der Verwendung von isset() oder empty().

    if (empty(isWorkDone())) {
        echo "done";
    }

    Beiden Funktionen müssen als Parameter jeweils Variablen übergeben werden. Wenn man ihnen einen Funktionsaufruf übergibt (was ja normalerweise kein Problem ist) spucken sie die oben genannte Fehlermeldung aus. Man muss also das Ergebnis des Funktionsaufrufs erst in eine Variable speichern und dann an isset() oder empty() übergeben.
    Es gibt ein RFC von Nikita Popov mit dem Vorschlag diese Einschränkung aufzuheben, das Voting läuft noch.

  3. Fatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
    Dieser Fehler trat früher auf wenn man eine nicht-statische Methode statisch aufgerufen hat, also mit einem ::. Und damit ist das Rätsel auch quasi schon gelöst, denn PAAMAYIM_NEKUDOTAYIM ist hebräisch und heißt “Doppel-Doppelpunkt” und steht damit für den Scope-Resolution-Operator. Warum schreibe ich früher? Weil diese Meldung mittlerweile geändert wurde, in aktuellen Versionen von PHP erhält man die aussagekräftigere Fehlermeldung
    Non-static method Audi::drive() should not be called statically

    class Audi
    {
        public function drive()
        {
            echo 'brumm brumm';
        }
    }
    
    Audi::drive();

    Mit wirklich falschem Code kann man ihn aber nach wie vor hervorlocken, beispielsweise:

    $var =  ;

    Fatal error: Parse error: syntax error, unexpected ‘;’, expected T_PAAMAYIM_NEKUDOTAYIM

Heutzutage zeigen gute IDEs alle diese Fehler bereits beim Programmieren an, vor wenigen Jahren war das noch nicht der Fall. Oder kann jemand für aktuelle Versionen von Netbeans, Eclipse, Zend Studio oder Komodo etc. sagen dass diese Fehler nicht erkannt werden?

Ihr habt ja wahrscheinlich auch schon so einiges gesehen an Fehlermeldungen. Was sind eure kuriosesten oder unverständlichsten Fehlermeldungen aus dem Webentwickler-Umfeld?



Keine ähnlichen Artikel.

Link
PHP Gangsta - Der PHP Blog mit Prax ...Linkpool Nummer 30 (6.5.2012, 09:30 UTC)

Hier einige Links die ich in den letzten 3 Wochen aufgeschnappt habe:

Einblicke hinter die Kulissen bei Draw Something, der am schnellsten wachsenden App:

Verbesserung der Disk-IO in Smarty:

Google HTML/CSS Style Guide:

Tips on Writing an API for a Smartphone App:

Warum readfile(), fread(), fpassthru() und stream_copy_to_stream() sich sehr ähnlich sind bzgl. Speicherverbrauch:

Die zweite Ausgabe des Web & PHP magazine:

Das Problem mit eigenen Session-Handlern und Destruktoren:

Mayflower Podcast #0004: Was haltet ihr von HTML5-Apps?



Ähnliche Artikel:

  1. Linkpool Nummer 28
  2. Linkpool Nummer 29
  3. Linkpool Nummer 27 + Adventskalenderartikel 10.12. – 24.12.
Link
PhpmonkeysMockito Magie (4.5.2012, 08:35 UTC)

Wer Unittests schreibt, weiß wie praktisch Mock-Objekte und die Frameworks sind, die diese zur Verfügung stellen. Heute konnte ich im Mockito-Java Umfeld etwas interessantes von einem Kollegen lernen und gebe das gerne weiter.

Mockito ist schon an sich ein sehr geniales Framework und es macht immer wieder Spaß verify zu benutzen. Mit dieser Funktion kann man überprüfen, ob eine Methode eines Mock-Objekts aufgerufen wurde. Selbstverständlich kann man diesen Aufurf noch genauer spezifizieren. Beispielsweise geht auch das Gegenteil – also wurde die Methode nicht aufgerufen. Oder man überprüft, ob diese x-mal aufgerufen wurde. Das liegt alles im Ermessen des Programmierers und wird dann sinnvoll eingesetzt.

Der wichtige Punkt ist, das man die Parameter einer Methode angeben muss. Man kann entweder einen festen Wert (oder genauer Objekt) angeben, oder einen Matcher nutzen. Matcher erlauben eine gewisse Varianz. Es ist somit möglich zu überprüfen, ob als Parameter eine Klasse des Typs Foo benutzt wurde. Ob das Objekt als valide Eingabe akzeptiert wird, hängt von der Implementierung des Matchers ab.
Nur der Sinn des Tests und die Lesbarkeit sind die Grenze dessen was man machen kann.

Richtig spannend ist der ArgumentCaptor. Dieser erlaubt es dem Entwickler einen allgemeingültigen Matcher für eine Klasse implizit zu definieren und man erhält auch noch Zugang zum eigentlichen Objekt. D.h. wenn ich wie im unten angeführten Beispiel weiß, dass meine UI im Test ein ResizeEvent feuert und ich den genauen Inhalt des Events benötige, ist der ArgumentCaptor genau die richtige Art und Weise, um den Inhalt relativ leicht zu bekommen.

ArgumentCaptor<ResizeEvent> resizeEventCaptor
   = ArgumentCaptor.forClass(ResizeEvent.class);
Mockito.verify(eventBusMock)
   .fireEvent(resizeEventCaptor.capture());
Assert.assertEquals(testPresenter.getMaxW(),
   resizeEventCaptor.getValue().getWidth());

In der ersten Zeile wird programmatisch der Captor erzeugt. Dessen capture Methode geben wir als Matcher an und nutzen verify wie wir es gewohnt sind. Da wir auf static-Imports verzichten ist der Aufruf etwas umständlich Mockito.verify. Danach kann man mit assertEquals den Inhalt des Captor-Werts vergleichen. Da der Captor mit Generics arbeitet kann man sich das Casting sparen.

Als kleine Ergänzung kann man statt des programmatischen Aufrufs auch mit Annotationen arbeiten. Dann gibt man @Captor an und schon wird das Attribut in einen Captor verwandelt. Man sollte hierbei nicht die Verarbeitung der Annotationen vergessen wie man sie von @Mock kennt.

Link
LinksRSS 0.92   RDF 1.
RSS 2.0 Feed   RDF 1.
100% Planet PHP   PHP5 powered
PEAR powered  
Code wird von Planet-PHP zur Verfügung gestellt. Vielen Dank.