static const?

[Kropff]

PS:
Ich habe nicht gesagt, man darf static nicht verwenden, sondern man sollte es meiden.

Das sehe ich anders. Wenn mehrere Objekte eine gemeinsame Basis benötigen, so sind statische Methoden und Eigenschaften eine Form von Kommunikation zwischen den einzelnen Objekten.

Peter

[combie]

Punkt 1:
Du spricht von "einer" Verbindung.
Aber ob nur "eine" oder auch mal "drei" gebraucht werden ist eine Anforderung der Applikation. Trägt man diese Anforderung "eine Verbindung" tief in untergeordnete Klassen hinein, dann leidet die Wiederverwendbarkeit dieser Klassen, ein Hauptvorteil der OOP ist damit verloren.

Und die 2:
Und nunja, dass du dem GC nicht traust, da kann ich dann auch nix daran machen...


PS:
Ich habe nicht gesagt, man darf static nicht verwenden, sondern man sollte es meiden.

[Kropff]

@combie und @Kropff
für meine Äußerung möchte ich mich ausdrücklich entschuldigen.

Damit ist von meiner Seite aus das Thema erledigt.

Ich möchte jedenfalls bei der Entwicklung komplexer Anwendungen auf die statischen Methoden und Eigenschaften nicht verzichten.

Man muß sie sicherlich nicht nutzen, aber da wo sie Sinn machen kann man sie schwerlich ersetzen.

Dem stimme ich voll zu!

Zum Thema "fortgeschrittenes Programmieren" kann ich auch die späten Artikel von Edsger W. Dijkstra empfehlen, der sich gewagt hat, folgendes zu behaupten: "Object-oriented programming is an exceptionally bad idea which could only have originated in California". Man kann ihn sicherlich kontrovers diskutieren, aber mir gefällt, daß er nicht an "Gott-gegebene Prinzipien" in der Software-Entwicklung geglaubt hat, wie so viele Informatiker heutzutage.

Das sehe ich persönlich ähnlich. OOP erzeugt immer einen ziemlichen "Wasserkopf". Und da muss man abwägen. Vielleicht liegt es auch einfach nur daran, dass Studenten nichts anderes mehr lernen. OOP ist eine wunderbare Sache, wenn man eine gemeinsame und einheitliche Basis für mehrere Programmierer benötigt. Aber es ist weiß Gott nicht der Stein der Weisen.

Peter

[thrashbarg]

Mea culpa

@combie und @Kropff

für meine Äußerung möchte ich mich ausdrücklich entschuldigen. Auch wenn bis dahin kein Versuch einer sachlichen Erklärung für die Aussage
["static" sollte man meiden, so wie der Teufel das Weihwasser] gemacht wurde, rechtfertigt das nicht eine unsachliche Antwort meinerseits.

Aber was soll das heißen, "Statische Methoden und Eigenschaften machen die Vererbung kaputt" ?

Und die Antwort auf mein (zugegebenermaßen sehr simples) Beispiel verstehe ich ehrlich nicht so ganz. Warum geht vererben nicht, wenn man mal kleinere Bugs bei der Implementierung in PHP außen vor läßt, die aber mit dem Prinzip ja nichts zu tun haben ? Und wo soll die Verbindung herkommen, die ich den Objekten mitgebe ? Außerhalb erzeugt ? Woher weiß ich, welches Objekt das zuerst erzeugte ist, damit ich die Verbindung generieren und übergeben kann. Oder generiere ich sie auf Verdacht, obwohl evtl. gar kein Objekt erzeugt wird, weil ich diese nur brauche, wenn irgendwelche Exceptions geworfen werden ? Und wo residiert diese Verbindung dann, in einer globalen Variablen ? Das hat dann aber mit OOP nicht mehr viel zu tun ...
Und daß mit dem Zerstören des letzen Objekts keine Referenz mehr auf die Verbindung existiert halte ich, bei Übergabe an eine Methode, für ein Gerücht.
Mein Beispiel zielte aber auch eindeutig auf den Fall hin, daß ich für eine beliebige Anzahl Objekte einer Klasse immer die gleiche Verbindung brauche, weil ich zum Beipiel Fehlermeldungen loggen oder den System-Administrator anmailen möchte.

Ich möchte jedenfalls bei der Entwicklung komplexer Anwendungen auf die statischen Methoden und Eigenschaften nicht verzichten.

Man muß sie sicherlich nicht nutzen, aber da wo sie Sinn machen kann man sie schwerlich ersetzen.

Zum Thema "fortgeschrittenes Programmieren" kann ich auch die späten Artikel von Edsger W. Dijkstra empfehlen, der sich gewagt hat, folgendes zu behaupten: "Object-oriented programming is an exceptionally bad idea which could only have originated in California". Man kann ihn sicherlich kontrovers diskutieren, aber mir gefällt, daß er nicht an "Gott-gegebene Prinzipien" in der Software-Entwicklung geglaubt hat, wie so viele Informatiker heutzutage.

Objekt-orientierte und Objekt-basierte Sprachen sind übrigens auch zwei verschiedene Paar Schuhe, das bedeutet Äpfel mit Birnen zu vergleichen.

[combie]

Das gilt auch für Iteratoren (im Speziellen) und die SPL (im Allgemeinen).

Richtig...!

Und das mit dem Self und den Klassen Constructoren wird sicherlich nicht vor PHP 9.6.3 eingeführt.


---------------

Als einfaches Beispiel sei genannt, wenn man die Anzahl instanziierter Objekte einer Klasse benötigt, weil man beim ersten instanziierten Objekt eine Verbindung irgendwohin öffnet, die man beim letzten zerstörten Objekt wieder schließt.

Was passiert, wenn du mal eine zweite, gleichartige, bzw. ähnliche Verbindung brauchst?
Alles doppelt schreiben? Weil, vererben geht ja nicht....
Oder irgend ein Gefuddel mit Arrays und get_called_class()?

Wäre es nicht besser den Objekten die Verbindung zu übergeben?
Z.B. über den Constructor, oder Setter...
Wenn dann alle Objecte "verbraucht" sind, gibts keine Referenz mehr auf die Verbindung und sie wird automatisch von GC entsorgt, incl. Destructor Aufruf. Sofern die Verbindung denn in einer Klasse gekapselt ist.
Vererben: Kein Problem.
Mehrfach Verbindungen: Kein Problem.

Meine Meinung: Für diesen Zweck brauchts kein "static".

[fireweasel]

[grins]
Wenn man einmal begriffen hat, wie ein Hammer funktioniert, dann sieht die ganze Welt plötzlich wie ein Nagel aus.
[/grins]

Das gilt auch für Iteratoren (im Speziellen) und die SPL (im Allgemeinen).

Tja, in punkto Software-Entwicklung gibt es kaum einen Hammer, den ich seit 1974 nicht in der Hand gehabt habe ...

Wuhaa, da waren einige von uns ja noch nicht einmal geboren ...!

Die Zahl der sinnvollen Anwendungen ist unbegrenzt und statische Methoden und Eigenschaften sind für fortgeschrittenes Programmieren wirklich unerlässlich ...

Es soll objektbasierte Sprachen geben, die kennen sowas wie Klassen (und damit statische Methoden) gar nicht. Du willst doch nicht sagen, dass mit denen kein "fortgeschrittenes Programmieren" möglich wäre? Gerade für das von dir als Beispiel angegebene Problem ...

Als einfaches Beispiel sei genannt, wenn man die Anzahl instanziierter Objekte einer Klasse benötigt, weil man beim ersten instanziierten Objekt eine Verbindung irgendwohin öffnet, die man beim letzten zerstörten Objekt wieder schließt.

... gibts auch Lösungen ohne Klassen.

Außerdem finde ich Klassen in PHP sowieso nur halbherzig implementiert: Es fehlt soetwas wie Konstruktoren und Destruktoren für Klassen. Eine vernünftige Benutzung von "self" wurde versemmelt, um in PHP 5.3 für das Schlüsselwort "static" noch eine zusätzliche Verwendung einbauen zu können. Das sieht mir nicht nach planvollem Vorgehen aus. Aber als billiger Namespace-Ersatz haben Klassen in PHP (kleiner 5.3) ganz gut getaugt.

[Kropff]

Bitte alle schön sachlich bleiben und von persönlichen Angriffen Abstand halten!

Genau, sonst mache ich hier dicht.

@trashbag
Hier im Forum wird das rhetorische Mittel der Ironie sehr gerne benutzt. Wenn du also keinen Humor, dann ist das dein Problem. Fasse daher solche Artikel wie den von combie nicht als persönlichen Angriff auf!

Peter

[AmicaNoctis]

Bitte alle schön sachlich bleiben und von persönlichen Angriffen Abstand halten!

[combie]

PHP expert hin oder her, sorry wenn ich das mal so sagen muß:

Das ist ein automatisch vergebener Titel und hat nichts mit meine Fähigkeiten zu tun.

[unset]

Ja, jetzt wissen wir alle, dass du ein ganz toller Hecht bist. Und trotzdem: Weder du noch sonst irgendwer hat die Weisheit mit Löffeln gefressen und es gibt immer mehrere Betrachtungswinkel. Wichtig ist in erster Linie zu hinterfragen.

[thrashbarg]

Das macht eine falsche Aussage auch nicht richtig ...

Tja, in punkto Software-Entwicklung gibt es kaum einen Hammer, den ich seit 1974 nicht in der Hand gehabt habe und in der Handhabung einiger war ich sogar so gut, daß ich den Umgang damit an der Hochschule weitergeben durfte ...

PHP expert hin oder her, sorry wenn ich das mal so sagen muß:

Wer solche Behauptungen aufstellt, sollte sich überlegen ob er das Programmieren nicht meiden sollte, wie der Teufel das Weihwasser ...

[combie]

[grins]
Wenn man einmal begriffen hat, wie ein Hammer funktioniert, dann sieht die ganze Welt plötzlich wie ein Nagel aus.
[/grins]

[thrashbarg]

Auch als Empfehlung absolut ungeeignet !

Statische Methoden und Eigenschaften sind sogar absolut sinnvoll !

Als einfaches Beispiel sei genannt, wenn man die Anzahl instanziierter Objekte einer Klasse benötigt, weil man beim ersten instanziierten Objekt eine Verbindung irgendwohin öffnet, die man beim letzten zerstörten Objekt wieder schließt.

Für statische Eigenschaften lassen sich noch viel leichter Beispiele finden, denn jedem dürfte klar sein, daß es mitunter Eigenschaften gibt, die für alle Instanzen einer Klasse gleich sind.

Die Zahl der sinnvollen Anwendungen ist unbegrenzt und statische Methoden und Eigenschaften sind für fortgeschrittenes Programmieren wirklich unerlässlich ...

Solche Behauptungen aufzustellen ist absolut unverantwortlich, weil weniger erfahrene Entwickler das für bare Münze nehmen könnten !

[fireweasel]

Ich hab eine Klassen variable, die ist protected static. Ich benötige aber den Inhalt dieser Variable unmodifizierbar, will den Inhalt aber nicht ständig kopieren.
Ist das möglich?
Wenn ich einen getter für ein Array schreibe, so gebe ich ja entweder eine Kopie (zu viel copy overhead) oder als referenz, dann kann ich die aber gleich public static machen, denn veränderbar ist der Inhalt.

Wie komm ich da raus? Ich hab ne hand voll statics, die ich für die API bereitstellen will, aber explizit vermeiden muss, dass jemand die variablen ändern kann

Niemand verbietet dir, eine Klassen-Methode zu schreiben, die ein Array zurückliefert.
So lange du nur lesend auf dieses Array zugreifst, wird auch nichts kopiert.

Edit: Zu blöd das die const geschichte bei Arrays nicht klappt

Nun, zumindest bei "resources" klappt sie. Ist wahrscheinlich ein Bug, aber es ist möglich einer Konstanten eine Ressource (die doch eigentlich veränderlich ist) zuzuweisen:

define('zomfg', fopen('facepalm', 'rb'));
define('phpsucks', imagecreate(100, 100)); 

Und seit ich durch Zufall dahintergekommen bin, wie private und protected(e) Properties in der internen Hashtabelle eines Objekts "versteckt" werden, bin ich mir nicht mehr so sicher, ob man nicht auch Klassenkonstanten ein Array zuweisen kann. Man müsste nur die passende Hash-Tabelle dazu finden ...

[Seikilos]

Jau, wollte keine Wellen aufwerfen. Solche posts kommunizieren die Intention des Schreibers schlecht. Wenn es eine Empfehlung war, dann danke ich dir dafür.

Zu dem const, danke, hatte das immer gelesen, aber war mir nicht sicher, ob es dadurch auch static ist.

Warum ich static brauche ist ganz einfach: Ich nutze Propel als ORM und das nutzt Instanzen von Klassen für die Relationenabstraktion und statische Klassen als Controller fürs fetchen der jeweiligen Instanzen.

Foo.class.php <- Klasse für Relation Foo, nur instatiiert.
FooPeer.class.php <- rein statische Klasse fürs holen der Foos. Diese Klasse hat nur reine statische Methoden, weil diese nur Ergebnisse generiert und keinen eigenen Zustand besitzt