[Erledigt] Type Casting

[Paul.Schramenko]

Als erstes Mal: Bin mir nicht sicher ob ich hier richtig bin, da ich aber davon ausgehe, dass diese Idee als Software Design gedacht ist, poste ich dies hier rein.

Zur Entstehung der Gedanken:
Hab mir am Wochenende als ich in der Badewanne lag ein paar Gedanken zu OOP gemacht und mir kam dann mit dem Ausruf: "Heureka!", die Idee:

Extreme Type Casting
Was andere Programmiersprachen, wie Java, C oder andere, können kann PHP doch schon längst!

Wieso nicht für alle Datentypen Objekte anlegen? Dann hätte man doch wesentlich weniger Validierungsarbeit. Man müsste nur einmal am Anfang ein paar Gedanken machen. Sich für verschiedene Datentypen Klassen anlegen. dann könnte man sich doch viel Validierungsarbeit sparen, da ja sowieso gewährleistet ist, welche Datentypen in die Klassen kommen.

Ich hab da mal was vorbereitet:

Abstrakte Klasse Datatype

<?php
    abstract class Datatype
    {
        protected $_value;
        
        public function __construct($value)
        {
            $this->_value = $this->_validate($value);
        }
        
        public function __toString()
        {
            return (string)$this->_value;
        }
        
        public function get()
        {
            return $this->_value;
        }
        
        abstract protected function _validate($value);
    }

Klasse für Integer

<?php
    class MyInt extends Datatype
    {
        protected function _validate($int)
        {
            if ($int !== null && preg_match("/^\d*$/", $int) > 0) {
                return (int)$int;
            }
            return 0;
        }
    }

Klasse für Boolean

<?php
    class MyBool extends Datatype
    {
        protected function _validate($bool)
        {
            if (is_bool($bool)) {
                return $bool;
            } elseif (preg_match("/^[0-1]{1}$/", $bool) > 0 && in_array($bool, array(0,1))) {
                return ($bool ? true : false);
            }
            return false;
        }
    }

Verwendung der Datentypen-Klassen:

<?php
    class Artikel
    {
        private $_artikelID,
                $_active;
                
        public function __construct(MyInt $id, MyBool $active)
        {
            $this->_artikelID = $id;
            $this->_active = $active;
        }
        
        public function test()
        {
            echo 'ArtikelID: ' . $this->_artikelID->get() . '<br />'.
                 'Active: ';var_dump($this->_active->get());
        }
    }
    
    $artikelID = new MyInt(5);
    $active = new MyBool('false');

    $test = new Artikel($artikelID, $active);
    $test->test();

Ausgabe

ArtikelID: 5
Active: bool(false)

Ich wollte einfach mal eine Diskussion anstoßen im Bezug auf so ein Software-Design.
Für wie sinnvoll haltet ihr diese Idee?

[PhillKill12]

aslo folgendes, imho ist Extrem Type Castig, so wie du es hier vorstellst z.b. MyInt $zahl ist doch das gleiche wie (int) $zahl, oder denke ich da falsch ..?

[Paul.Schramenko]

Es geht ja darum, dass ich den Klassen und Funktionen auf eine umfangreichere Validirung verzichten, da sowieso gewährleistet ist, welche Datentypen rein kommen.
Zumindest war das mein Gedankengang...

<?php
...
public function test(MyInt $int)
{
    ...
}
...

[Paul.Schramenko]

Natürlich könnte man das ganze noch weiter treiben und sich eine Abstrakte Klasse schreibe.
Und in den abgeleiteten Klassen dann nur noch die _validate() und die __toString() Methode überschreiben.


Hab mich doch dafür entschieden ma schnell ne Abstrakte Klasse hinzu zu fügen....

[draco88]

Die Idee ist so schon in neuere PHP-Versionen mit der SPL intigriert.
PHP: SPL Types - Manual

Da PHP-OOP aber doch um einiges langsammer ist als z.B. Java würd ich mir solche Objekt sparen und lieber "per Hand" also mit is_int o.ä. abfragen.
Es hat mit Sicherheit seine Vorteile, aber ich finde nicht, dass es den zusätzlichen Aufwand wirklich lohnt. Aber das muss jeder für sich entscheiden.

[Paul.Schramenko]

Ab welcher PHP-version ist das denn verfügbar? Warscheinlich erst ab 5.3 oder?

Naja ich dachte nur, da ich immer soviel bei der Validierung von Werten Code schreiben muss, dachte ich mir, das ganze könnte man sich doch auch sparen in dem man einfach mit Klassen arbeitet, die genau das darstellen, was du erwartest!

[robo47]

Das Problem mit dem ganzen ist halt der aufwand, jedesmal von primitiven Typen Objekte zu erstellen und die daraus resultierende Konsquenz, dass man damit einfache Typen referenziert, sprich Änderungen am objekt sind damit auch bei den einfachen typen vorhanden (Ausser man nutzt Value-Objects/Value Object bei Fowler, was hier Sinn machen würde) und viel wichtiger, man muss entweder sich immer von den objekten die werte besorgen zum rechnen oder sämtliche mathematischen und anderen möglichen funktionen (+-*/%& .... ), weil überladen kann man die operatoren in php nicht.

Ansonsten erinnert mich das etwas an den Vortrag von Sebastian Bergmann, wo es darum geht typensichere properties in objekten zu realisieren.
Type-Safe Objects in PHP


Ich würde ich mir auch typehints für einfache Datentypen in PHP wünschen, vielleicht für 6.0 oder so
-> Scalar type hints in PHP - Blog - Open Source - schlitt.info
-> Type hinting for PHP 5.3 - iBlog - Ilia Alshanetsky

[Paul.Schramenko]

Ansonsten erinnert mich das etwas an den Vortrag von Sebastian Bergmann

Ich hab auf PHP Summit leider keinen Vortrag von Bergmann gehört. Aber

wo es darum geht typensichere properties in objekten zu realisieren.
Type-Safe Objects in PHP

Genau darum geht es mir.

Ich würde ich mir auch typehints für einfache Datentypen in PHP wünschen, vielleicht für 6.0 oder so

Das würde mir sehr gefallen, das wäre es auch wesentlich einfacher bestehende Software andere Programmierer zu lesen, da man in den einzelnen Funktion genau weiß was reinkommen MUSS.

[Anyone]

Ich habe bereits deine Idee vor einigen Monaten gehabt und ich kann dich in dieser Hinsicht nur unterstützen. Bei nicht performance-kritischen Anwendungen können selbst geschriebene Datentypen sogar einen entscheidenen Vorteil bringen. Ich hatte beispielsweise eine simple Klasse (Decimal), mit der ich natürlich verschiedene Objekte mit verschiedenen Dezimalzahlen gefüllt hatte. Der Knackpunkt war, dass ich die Ausgabe des Wertes je nach gewünschtem Standard (Deutsch = 3,14... ; Englisch = 3.14...) bequem steuern konnte. Ich hatte mir sogar die Möglichkeit offen gelassen, dass der Programmierer verschiedene .ini Dateien für verschiedene Sprachstandards schreiben kann. So konnte jeder Sprachstandard berücksichtigt werden. Das ganze sah dann folgendermaßen aus:

$decial = new Decimal(3.14);
echo $decimal->get('ger'); // Ausgabe 3,14
echo $decimal->get('eng'); // Ausgabe 3.14 

Vielleicht bietet PHP sogar native Funktionen dafür, dennoch erachte ich diese Vorgehensweise als sehr bequem. Die Angabe der Sprache war natürlich ein optionaler Parameter. Nun könnte man in dieser Hinsicht weiter denken. Da du im Stande bist "eigene Datentypen" zu programmieren, könntest du dir beispielsweise eine schöne Datums- oder Zeitklasse schreiben. Dir bleiben in diesem Zusammenhang viele Möglichkeiten offen und bei nicht performance-kritischen Anwendungen überwiegen die Vorteile nach meinem Dafürhalten.

[nikosch]

$decial = new Decimal(3.14);
echo $decimal->get('ger'); // Ausgabe 3,14
echo $decimal->get('eng'); // Ausgabe 3.14 

Das hat aber nichts mit Typsicherheit zu tun. Sondern mit der Ausgabesteuerung.

Ich finde Typen auf diesem Weg umzusetzen ultra-sperrig. Vor allem bei Arrays auf die Sprachkonstrukte und Operatoren verzeichten zu müssen, macht alles total kompliziert. Der Code wird unlesbar und die Zeilen lang.

[Anyone]

Das hat aber nichts mit Typsicherheit zu tun. Sondern mit der Ausgabesteuerung.

Das sollte lediglich eine kleiner Exkurs sein. Damit wollte ich nur weitere Möglichkeiten für individuelle Datentypen aufzeigen. Jedem bleibt dann die Möglichkeit offen, neben primitiven Datentypen ebenfalls komplexe "Datentypen" (Datum, Zeit etc.) zu realisieren.

[Koala]

ob da ein Punkt oder Komma hinkommt ist meines Erachtens ein typischer Fall von viewhelper.
Ebenso die angesprochen Ausgabe-Formatierungen für Zeit/Datum.

Ich hab übrigens öfter mal Auftraggeber die auf deutschen Seiten
auf der englischen Schreibweise bestehn.

Ist wohl cooler ...

[Chriz]

Hallo,
hab beim Rauchen auch immer fabelhafte Ideen. Deine ist aber nicht neu, extrem unperformant und hat wie schon gesagt den Nachteil, dass Operatoren nicht überladen werden können, sprich du wieder langsame Methoden aufrufen musst ($int->add($int2)). Ich bin ja auch ein Fan davon, aus allem Objekte zu machen, aber den Geschwindigkeitsnachteil merkt man schon so mehr als deutlich. Jeden Wert jetzt zu einem Objekt zu machen ist performance-technischer Selbstmord. Mir reicht es eigentlich bei Datenbankabfragen etc. ein (int) Typecast vor den Wert zu knallen um auf der sicheren Seite zu sein. Was mich noch etwas stört sind eher Strings und ihre unterschiedlichen Zustände (enthält HTML, darf HTML enthalten, ist escaped, ...). Da solls ja zumindest in PHP 6 einen internen Flag zu geben, der einen Notice wirft, wenn ein String ausgegeben aber nicht zuvor abgesichert wurde.

Ich rat dir also eher davon ab. Aber kannst du das Problem nicht umgehen, in dem du Objekte für deine Datenbankabbildungen hast, die bereits beim Setzen den Wert validieren:
Die endlose Geschichte: http://www.php.de/tutorials/54558-tu...l-und-oop.html

Wobei ich mir mittlerweile einen Generator geschrieben habe, der aus dem Datenbankschema Objekte erzeugt inklusive entsprechender Validierung, also ein kleines OR-Mapping:

<?php 
// VARCHAR(255)
const MAXLENGTH_TITLE = 255; // für Formulare
public function setTitle($title) {
  if (is_string($title)) {
    $title = mb_substr($title, 0, 255);
  }
  $this->_title = $title;
  return $this;
}
// UNSIGNED INT(11), NOT NULL
public function setValue($value) {
  $this->_value = max(0, (int)$value));
  return $this;
}
?>

<?php
$myObject = new MyObject();
$myObject->setTitle($_POST["title"]);
$myObject->setValue($_POST["value"]);
echo htmlentities($myObject->getTitle() . "," . $myObject->getValue());
?>

Dir validiert also die Klasse - die durch den Generator ja die erlaubten Wertigkeiten kennt - schon deine Werte, wenn du sie einmal durchschleust.

Ich finde das reicht schon soweit aus um Wertigkeiten einzuschränken.

[agrajag]

Ich persönlich finde es auch extrem hässlich das so zu lösen. PHP ist dazu einfach nicht geeignet und hat andere Stärken.

Was mich noch etwas stört sind eher Strings und ihre unterschiedlichen Zustände (enthält HTML, darf HTML enthalten, ist escaped, ...). Da solls ja zumindest in PHP 6 einen internen Flag zu geben, der einen Notice wirft, wenn ein String ausgegeben aber nicht zuvor abgesichert wurde.

Das ist in der neuen Rails-Version ziemlich geil gelöst: Gibst du einen String aus wird er automatisch escaped, es sei denn du markierst ihn sozusagen vorher mit "mein string".html_safe

Ich glaube bei symfony gibt's was ganz ähnliches (zumindest den "automatisch escapen"-Teil)

[Chriz]

Wie machen die das denn?