Umfrage: Typ-sicheres PHP durch neue Basis-Typen

[alxy]

Super, funktioniert!

 

[alxy]

Aber warum du die jetzt nochmal neu machst, verstehe ich nicht. Die machen doch genau, was du willst und zusätzlich sind alles Stringfunktionen auch mit ihnen möglich:

<?php

$string = new SplString("Testing");
$string = strtoupper($string);

var_dump($string);

object(SplString)#1 (1) { ["__default"]=> string(7) "TESTING" }

 

[saftmeister]

Es wäre am besten, wenn du es selbst kompilieren würdest, evtl. kann ja saftmeister die Projektdateien mitgeben.

Gern, wenn es noch jemand selbst machen will, im Anhang der komplette Source + VS2008 Projekt-Dateien. Die local.vsprops muss angepasst werden, denn da stehen ja momentan meine lokalen Pfade drin.

PHP_SOURCE_FOLDER = Pfad zu den entpackten Source-Code-Dateien von PHP der gewünschten Version
PHP_BIN_FOLDER = Pfad zu entpackten Dateien des PHP-Release-Zips (oder auch nach xampp\php wenn es dort einen Unterordner "dev" gibt, in dem die php5ts.lib drin ist)

Aber warum du die jetzt nochmal neu machst, verstehe ich nicht. Die machen doch genau, was du willst und zusätzlich sind alles Stringfunktionen auch mit ihnen möglich

Da ich die bis heute nicht kannte, erklärt sich das von selbst. Aber: Wir hatten heute das Thema schon mal, Objekt-Kontext usw.

 

[alxy]

Naja, PHP ist nunmal eine funktionale Sprache, sprich man arbeitet mit Funktionen
Jetzt könnte man natürlich eine Grundsatzdiskussion führen, ob man nicht alles in Objekten kapseln sollte, wie es in den neueren Erweiterungen von PHP der Fall ist, wie zB bei DOMDocument, PDO, ...
Der Weg, den PHP da geht ist relativ inkonsequent und teilweise sogar redundant, so werden für mysqli sowohl ein prozedurales(funktionales) als auch ein objektorientiertes Interface angeboten.
Ich weiß ehrlich gesagt nicht, was ich da besser finden soll. Ich programmiere erst seit einem Jahr, aber grade am Anfang hat mir diese "Einfachheit" bei PHP geholfen. Es geht einfach alles mit Funktionenen, Schleifen und Kontrollstrukturen.

 

[saftmeister]

Das sehe ich auch so. Wenn man aber versucht, den OOP-Ansatz konsequent zu fahren, stößt man immer wieder auf Hürden. Häufig muss man etwas selbst implementieren.

Der Ansatz, OOP zu verwenden ist ja auch nur dem Thread-Thema geschuldet, denn nur durch Klassen kann man typ-sicher in PHP sein.

 

[alxy]

Um zu diesem Thema zurückzukehren:

Welche konkreten Vorteile ließen sich für eine Klasse (zB "String") finden, die zusätzlich noch alle Stringfunktionen als Methoden zur Manipulation bereitsstellt? Ich sehe da keinen zusätzlichen Sinn. [Die Typsicherheit ist mir als Vorteil bewusst, ich rede jetzt von den zusätzlichen Methoden]

 

[saftmeister]

Um im Kontext des Objektes zu arbeiten. Also der volle OOP-Ansatz, wie du ihn heute im anderen Thread schon propagiert hast.

Natürlich kann man da jetzt so ran gehen:

class String extends SPLString
{
  public function toLower()
  {
    return strtolower($this);
  }

  /* usw... */
}

Aber dann hätte man wieder zwei Abhängigkeiten (SPL_Types + eine Sammlung von PHP-Scripts - die auch erstmal byte-code-kompiliert werden müssen). Außerdem verspreche ich mir einen Performance-Vorteil, wenn das ganze in optimierten C-Code läuft. Letztendlich muss es ohnehin wieder durch eine C-Schicht durch (da PHP ja in C geschrieben ist), dann kann man es auch gleich in C machen. Nicht zuletzt macht es Spaß und ich lerne was dabei.

Ich habe außerdem noch ein viel umfangreicheres Ziel, ich habe keine Ahnung, ob ich das jemals erreiche:

- Der globale Namensraum von PHP ist mit Funktionen vollgefrachtet, die sich teilweise gegenseitig ersetzen (gerade im Bereich Stringmanipulation)
- deren Funktionsnamen teilweise unterschiedlichen Paradigmen folgen
- die Parameterlisten teilweise ihn ähnlich gelagerten Funktionen unterschiedlich aufgebaut sind.

Kurzum PHP ist eine riesen Code-Müllkippe (nennt man glaub ich historisch gewachsen) und die Basis-Maintainer scheuen sich davor, endlich mal klaren Tisch zu machen, die Abwärtskompatibilität loszuwerden um ein in sich stimmiges Gesamt-Sprach-Paket zu veröffentlichen.

Mein Ziel ist eine eigene Version von PHP, die komplett objekt-orientiert und typ-sicher ist oder zumindest die Möglichkeit bietet, typsicher zu sein.

Mich nervt es einfach, das ich bei einer Variablen nicht weiß, was sich dahinter verbirgt, ohne entweder zu debuggen oder mit Kinkerlitzchen wie "var_dump" oder "print_r" zu arbeiten. Das ist IMHO unprofessionell.

Guten Code kann man direkt lesen

Da fragt sich vielleicht der eine oder andere: Warum um Himmelswillen nimmt er dann nicht Python oder Ruby? Ich habe bisschen was in Python gemacht. Die Sprache liegt mir nicht besonders. Ich bin in der Syntax von C zu Hause, und das ist auch das, was mich bei PHP hält. Ich kenne die Sprache seit ca 2001, also schon etwa 11 Jahre, habe sie noch erlebt, da war sie weit davon weg, OOP einigermaßen vernünftig drauf zu haben - da gab es sowas wie public oder private noch lange nicht - von Klassen im Standard-Raum ganz zu schweigen. Es war ein Quantensprung von PHP3 zu PHP4, was die Geschwindigkeit angeht. Seit PHP5.3 haben wir sogar Namensräume - auch wenn vermutlich kaum einer davon wirklich gebraucht macht (außer er/sie verwendet ein Framework wie Zend).

All die netten Dinge, die einem das Leben so unglaublich erleichtern, die sind jetzt da, neben dem alten Müll, bei dem man jedes Mal ins Handbuch schauen muss, um zu erfahren "Achja, das war die Funktion, bei der Parameter 1 und 2 vertauscht werden müssen".

Hier für alle die ähnlich empfinden oder Gründe dafür suchen: http://www.bitstorm.org/edwin/en/php/
Zugegeben, ein paar davon sind obsolet. Und hier auch noch was auf deutsch: http://www.heckmeck.de/computerstuff/scheiss_php/

Das muss doch eigentlich nicht sein ;-)

Aber wie schon geschrieben: Ich habe keine Ahnung, ob dieses Ziel jemals erreicht wird. Aber ich gehe kleine Schritte.

 

[alxy]

Ok, das war im Prinzip das was ich erwartet habe. Finde ich nicht schlecht, dass du das machst! Bin mal gespannt daruaf, da mal Ergebnisse zu sehen. (Am besten als fertige dlls, sonst für mich unbenutzbar )

Wobei ich nicht weiß, ob und wie sich das (selbst bei nativem C) auf die performance auswirkt, wenn wirklich alles und jedes ein Objekt ist...

 

[saftmeister]

Ok, das war im Prinzip das was ich erwartet habe. Finde ich nicht schlecht, dass du das machst! Bin mal gespannt daruaf, da mal Ergebnisse zu sehen. (Am besten als fertige dlls, sonst für mich unbenutzbar )

Ich werde mich so bald wie möglich hinsetzen und mal zunächst die String-Klasse für Windows gangbar machen. Für Linux läuft sie wie bereits erwähnt schon. Eine DLL zu zaubern ist keine hohe Kunst, wie du schon gemerkt hast ;-)

Wobei ich nicht weiß, ob und wie sich das (selbst bei nativem C) auf die performance auswirkt, wenn wirklich alles und jedes ein Objekt ist...

Ich weiß nicht, ob dir das jetzt was sagt, weil ich deinen Kenntnisstand zu Hochsprachen (keine Scriptsprachen) nicht kenne. Stelle dir vor, es gibt eine Klasse "Objekt", von der ist alles abgeleitet. So arbeitet Java. Stelle dir eine Klasse ohne Methoden nur mit Feldern vor, das nennt man eine Struktur. Im PHP-Kern sind ALLE! Variablen letzendlich Variablen vom Typ Struktur zval. Diese Struktur beinhaltet ein Feld mit dem Namen type. Dort drinnen wird gespeichert, was für ein PHP-Typ die Variable ist, also "string", "long" (steht auch für int), "bool" (ist eigentlich auch ein long), "array" (assoziative = hash) oder auch "object". Das ist der Grund, warum eine "1" bei arithmetischen Operationen eine 1 ist. Das heißt, letzendlich kann jede PHP-Variable ein Objekt sein. Der Speicher-Bedarf ist nur marginal größer (Funktionszeiger auf Konstruktor und so weiter muss man halt mit einrechnen).

Aber ich will hier keine Märchen erzählen und nur von Vorteilen berichten. Im derzeiten Stadium (nicht optimierten) ist die Klassen-Version etwas langsamer als prozeduraler Code. Hab grad keine Statistik zur Hand aber ich hab es schon nachgetestet (z.B. bei preg_replace() vs String::replace()). Aber da geht bestimmt noch was.