static const?

[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.

[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".

[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.

[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

[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]

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]

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

Wie wäre es mal mit einem konkreten Beispiel...

[fireweasel]

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.

Das wäre EIN Weg von mehreren. Du könntest auch ein zusätzliches Objekt erstellen, welches die Zusammenarbeit koordiniert.

[Kropff]

Das wäre EIN Weg von mehreren. Du könntest auch ein zusätzliches Objekt erstellen, welches die Zusammenarbeit koordiniert.

Das ist wie so oft Ansichtssache. Viele Wege führen nach Rom. Mich stört es aber, wenn nur ein(!) Weg progagiert wird. Wenn statische Eigenschaften und Methoden aus Sicht der Informatik Müll wären, hätte man sie nicht in diverse Sprachen eingebaut. Ich verweise hier nur auf Singletons.

Peter

[combie]

Ich verweise hier nur auf Singletons.

Die GoF beißen sich sicherlich mittlerweile in den Hintern, dass sie das mit aufgenommen haben...
Und auch für mich ist das eine echtes "anti Pattern".

[Kropff]

Was ist ein GoF? Ich kenne die FoBs und die FoGs. Aber GoFs? Btw: Ein Singleton ist kein Anti-Pattern. Es wurde nur zu oft bei jedem Mist progagiert. Zum Beispiel bei Datenbank-Verbindungen.

Peter

[combie]

Die "Gang of Four" haben ein durchaus lesenswertes Buch geschrieben.
u.A. hier erwähnt: Entwurfsmuster ? Wikipedia

Es wurde nur zu oft bei jedem Mist progagiert. Zum Beispiel bei Datenbank-Verbindungen.

100% richtig!

[fireweasel]

Das ist wie so oft Ansichtssache. Viele Wege führen nach Rom. Mich stört es aber, wenn nur ein(!) Weg progagiert wird.

Da widerspreche ich dir nicht.

Wenn statische Eigenschaften und Methoden aus Sicht der Informatik Müll wären, hätte man sie nicht in diverse Sprachen eingebaut.

Wende das Argument mal auf GOTO an ...

Hinzu kommt, dass (statische) Klassen in PHP nunmal "defekt", also nur eingeschränkt zu gebrauchen, sind.

... Ich verweise hier nur auf Singletons.

... Und auch für mich ist das eine echtes "anti Pattern".

Ich habe kein Problem mit dem Singleton-Pattern. Dass es falsch angewandt wird, ist eine Eigenschaft, die es mit anderen Werkzeugen teilt.

OffTopic:

---

Die GoF beißen sich sicherlich mittlerweile in den Hintern, dass sie das mit aufgenommen haben...

Das ist mir schnurz. Sowas kommt halt dabei heraus, wenn man die Realität in Schablonen pressen will.

---

Singletons sind insofern interessant, weil man sie in PHP nur mithilfe von statischen Methoden bauen kann (notfalls noch mit einer "gewöhnlichen" Funktion).

So wie ich das sehe, verhält sich eine Klasse mit statischen Methoden und statischen Eigenschaften auch wie ein Singleton, ist also nur ein anderer Name für (fast) das gleiche Konzept.

Und schließlich ist ein Singleton in PHP eine Alternative zu einer "rein statischen" Klasse, wenn sowas wie ein Konstruktor oder/und ein Destruktor gebraucht wird. Mehr als ein paar skalare Werte kann man einer Klasse bei der "Initialisierung" ja nicht mitgeben, und das "Aufräumen" am Schluss geht nur über Krücken.

[derschbedsi]

Ohmann ... als ich "public static sollte vermieden werden" gelesen hab hörte ich auch auf, den Thread zu verfolgen

Ohne global erreichbare, ungeschützte Objekte sind größere Projekte meist garnicht möglich - ein einzige Zugriffspunkt muss immer uneingeschränkt erreichbar sein wenn die Software lesbar sein soll und/oder von mehr Leuten als nur dem kleinen Hans in seinem Kinderzimmer gebaut wird

Das ist auch durchaus vertretbar - sofern diese variable oder dieses Objekt einigermassen isoliert ist und wirklich nur die wichtigsten Infos / Zugriffspunkte bietet. Das ist nunmal Fakt - da können sich einige Spezis im Internet auch noch so sehr gegen wehren.

Und nun viel Spaß beim Sabbern ob der Ironie meines Nicknames.

[AmicaNoctis]

Ohne global erreichbare, ungeschützte Objekte sind größere Projekte meist garnicht möglich - ein einzige Zugriffspunkt muss immer uneingeschränkt erreichbar sein

Das stimmt so nicht. Für Schnellschussprojekte oder Machbarkeitsstudien muss man static nicht dogmatisch vermeiden, aber wenn es um Wiederverwendbarkeit und Wartbarkeit geht, ist es gerade bei großen Projekten mehr als sinnvoll, dass man bessere Ansätze verwendet.

Dass große Projekte ohne static nicht auskommen würden, ist aber absolut unzutreffend. Es gibt so viele gute Entwurfsmuster, die einen würdigen Ersatz darstellen.