nicht angemeldet
Also ich bin eher gegen public Eigenschaften. Wobei deine Idee mich da schon wieder in Versuchung führt, da sie gut ist.
Für mich sind Eigenschaften jedoch etwas privates. Methoden dagegen sind Schnittstellen. Deshalb möchte ich nur über Schnittstellen kommunizieren. Außerdem hab ich da mal einen Artikel über "method chain" gelesen der mich aufhorchen hat lassen.
Für alle die nicht wissen was "method chain" ist:
Es gibt Methoden die geben nichts zurück - void. Anstatt nichts zurück zu geben könnte man die instanz des eigenen Objektes zurück geben. Dann kann man gleich die nächste Methode des Objektes aufrufen:
$objObjekt->methode1()->methode2()
Der Artikel ging über Java7. Darin soll es einen Chaingkontroll geben, der definiert in welcher Reihenfolge die Methoden aufgerufen werden müssen.
Als Beispiel:
Es gibt eine (schlechte) Klasse welche einen Datenbankzugriff regelt. Man muss in ein Objekt dieser Klasse erstmal Datenladen um diese dann speichern zu können, also:
$objDatabase->setData($arData)->save();
Andersrum würde es keinen Sinn machen. Die Methoden haben also einen logischen Ablauf. Ruft man die Methoden trotzdem andersrum auf passiert gar eventuell nichts. Es ist ja kein Programmierfehler. Der Compiler oder Interpreter schluckt das ganze. Fehler bekommt man dann bei der Ausführung, wenn z.B. Daten falsch oder gar nicht abgespeichert werden. Deshalb soll man über ein Interface (oder wie auch immer) angeben können in welcher direkten Logischen Reihenfolge die Methoden aufgerufen werden müssen. Also hier wäre der Ausdruck in etwas: save darf erst aufgerufen werden, wenn setData min. 1 mal aufgerufen wurde. Verstößt man gegen diese Angabe meckert der Interpreter oder der Compiler. Man merkt den Fehler also sofort beim testen.
Deshalb setze ich auf Methoden (und hab mir angewöhnt bei void Methoden ein this zurück zu geben). Deine magischen Methoden würden den oben beschriebenen Ansatz nicht schaffen.
(bisschen Ausschweifung)
Ja c steht für Class. Hab mir allerhand Namenskonventionen angewöhnt:
obj = Objekt
ar = Array
str = String
int = Integer (alle ganzen Zahlen, auch bigint)
flt = Float (alle Zahlen mit möglichem Komma)
node = Knoten (xml oder html knoten)
id = Ids für Knoten (vor allem im Javascript)
file = Dateihandler
bool = true / false
Ich glaube das waren die sinnvollsten. Dein Beispiel wäre natürlich eine Ausnahme. Wenn ich nicht weiß was für ein Typ in einer Variable sein könnte, benutze ich keine Vorangestellten Zeichen. In dem Fall wäre es einfach $foo. Es könnte aber auch sein, dass ich die Namenkonvention mit der größten Wahrscheinlichkeit nehme. Sprich ich erwarte dass $foo ein false ist, werde ich $boolFoo nehmen. Erwarte ich einen Integer dementsprechend $intFoo. Das c für Klassen ist quatsch, da ich jedoch den zweiten Buchstaben großschreibe sieht es optisch einfach ein bisschen besser aus.
Gruß
tRex