nicht angemeldet
Tach!
Die Lebensdauer eines Cookies ist nichts, was essentiell als Wissen in diese Cookie-Klasse gehört. Die Cookie-Klasse sollte explizit einen vom Programmierer anzugebenden Wert fordern. Der Programmierer muss also "14 Tage" als Zeitdauer hineingeben.
Speziell beim Cookie bedeutet eine nicht gesetzte Lebensdauer, dass es die Browser-Sitzung nicht überlebt. Systemimmanent ist also anderenorts schon ein Default-Wert festgelegt. Aber wir sollten hier nicht generell über Cookies reden, sondern annehmen, dass der Anwendungsfall hier eine Festlegung der Lebensdauer erfordert und 14 Tage der übliche Standardwert dafür ist.
Damit verbunden dann die Frage: Was macht einen Wert so besonders, dass er Default-Wert sein soll?
Es ist ein Wert, der für einen Großteil der Anwender sinnvoll ist, für den Rest aber angepasst werden können soll.
Für welche Dinge ist es denn überhaupt sinnvoll, alternativ zu einem explizit abweichenden Wert ein Default-Verhalten zu implementieren? Kann man nicht einfach zwingend fordern, dass der Programmierer immer einen Wert konfiguriert - und der konfigurierte Wert ist dann der finale Wert? Das macht die Dinge einfacher, weil kein geheimnisvoller Default-Wert ins Spiel kommt, sondern von vorn bis hinten nur ein einziger Wert relevant ist.
Geheimnisvoll ist er nur ohne Dokumentation.
Denn wenn du mit zwei Werten arbeitest, dem "normal konfigurierten" und dem "Default", dann wäre die nächste Frage: Wenn ich den normalen Wert konfigurieren kann, wie konfiguriere ich dann den Default-Wert?
Ein Default-Wert ist einer der wirkt, wenn nichts angegeben ist. Was soll ein Programm denn machen, wenn in keiner Konfigurationsdatei ein Wert zu finden ist? Radikal solange Fehlermeldungen werfen, bis selbst alle unwichtigen Konfigurationswerte bedient worden sind? Ich denke, mit solch einer "Gängelei" macht man sich weniger Freunde als die Einhaltung solcher Prinzipien wert ist. Ich sehe auch nicht, dass das gängige Praxis ist. Wie machen es dann die Projekte, die von Hinz und Kunz verwendet werden, und bei denen davon ausgegangen werden muss, dass Konfigurationswerte aus den mitgelieferten Dateien gelöscht werden? Umgehen die aus der Sicht des Codes das Problem, indem sie eine interne nicht durch Endanwender änderbare Default-Werte-Konfigurationsdatei haben? Oder wie löst man das Problem des Konkurrenzkampfes zwischen Prinzip und Benutzerfreundlichkeit?
Und an der Stelle schließt sich der Kreis, und das Sonderbehandeln eines Default-Werts wird sinnlos oder besonders aufwendig. Man kann nicht ZWEI Werte für einen Parameter zur selben Zeit haben, wirksam werden kann immer nur ein einziger.
Besonders aufwendig ist der ternäre Operator nun auch wieder nicht.
wert = konfigurierter_wert ?: defaultwert;
Oder auch die Langform, wenn diese Kurzschreibweise nicht verfügbar ist.
wert = isset(konfigurierter_wert) ? konfigurierter_wert : defaultwert;
Ich mag auch eigene Funktionen/Methoden mit optionalen Parametern nicht wirklich. Wozu sollen die gut sein?
Wozu soll eine pauschale Ablehnung gut sein? Warum muss ich immer etwas angeben, wenn ich nur gelegentlich Abweichungen von einem Standardverhalten haben möchte?
In der Regel rufe ich die Funktion immer mit dem vollen Satz an Parametern auf, die alle durch Variablen befüllt werden, die anderswo herkommen. Ich liefere also immer Werte, so dass kein Parameter jemals "optional" ist. Ich kann mir also sparen, den Parameter optional zu machen, weil dieser Anwendungsfall nicht auftritt, und ich spare mir, diesen Sonderfall extra zu testen.
Wie hältst du es bei Sprachen, die verschiedene Methodensignaturen erlauben? Sag jetzt nicht, es gibt bei dir dann nur eine, egal wie lang der Parameter-Rattenschwanz selbst im Default-Fall wird.
dedlfix.