Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Type Casting

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Type Casting

    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-Code:
    <?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-Code:
    <?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-Code:
    <?php
        
    class MyBool extends Datatype
        
    {
            protected function 
    _validate($bool)
            {
                if (
    is_bool($bool)) {
                    return 
    $bool;
                } elseif (
    preg_match("/^[0-1]{1}$/"$bool) > && in_array($bool, array(0,1))) {
                    return (
    $bool true false);
                }
                return 
    false;
            }
        }
    Verwendung der Datentypen-Klassen:
    PHP-Code:
    <?php
        
    class Artikel
        
    {
            private 
    $_artikelID,
                    
    $_active;
                    
            public function 
    __construct(MyInt $idMyBool $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
    Code:
    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?
    "My software never has bugs, it just develops random features."
    "Real programmers don't comment. If it was hard to write, it should be hard to understand!"


  • #2
    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 ..?
    PHP-Code:
    if ( $humans >= ) {
       
    war ();

    Kommentar


    • #3
      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-Code:
      <?php
      ...
      public function 
      test(MyInt $int)
      {
          ...
      }
      ...
      "My software never has bugs, it just develops random features."
      "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

      Kommentar


      • #4
        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....
        "My software never has bugs, it just develops random features."
        "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

        Kommentar


        • #5
          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.

          Kommentar


          • #6
            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!
            "My software never has bugs, it just develops random features."
            "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

            Kommentar


            • #7
              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
              robo47.net - Blog, Codeschnipsel und mehr
              | Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

              Kommentar


              • #8
                Zitat von robo47 Beitrag anzeigen
                Ansonsten erinnert mich das etwas an den Vortrag von Sebastian Bergmann
                Ich hab auf PHP Summit leider keinen Vortrag von Bergmann gehört. Aber

                Zitat von robo47 Beitrag anzeigen
                wo es darum geht typensichere properties in objekten zu realisieren.
                Type-Safe Objects in PHP
                Genau darum geht es mir.

                Zitat von robo47 Beitrag anzeigen
                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.
                "My software never has bugs, it just develops random features."
                "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

                Kommentar


                • #9
                  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:

                  PHP-Code:
                  $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.

                  Kommentar


                  • #10
                    PHP-Code:
                    $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.
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #11
                      Zitat von nikosch Beitrag anzeigen
                      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.

                      Kommentar


                      • #12
                        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 ...
                        Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                        Kommentar


                        • #13
                          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-Code:
                          <?php 
                          // VARCHAR(255)
                          const MAXLENGTH_TITLE 255// für Formulare
                          public function setTitle($title) {
                            if (
                          is_string($title)) {
                              
                          $title mb_substr($title0255);
                            }
                            
                          $this->_title $title;
                            return 
                          $this;
                          }
                          // UNSIGNED INT(11), NOT NULL
                          public function setValue($value) {
                            
                          $this->_value max(0, (int)$value));
                            return 
                          $this;
                          }
                          ?>
                          PHP-Code:
                          <?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.
                          "Mein Name ist Lohse, ich kaufe hier ein."

                          Kommentar


                          • #14
                            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.

                            Zitat von Chriz Beitrag anzeigen
                            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)
                            Create your own quiz show.

                            Kommentar


                            • #15
                              Wie machen die das denn?
                              "Mein Name ist Lohse, ich kaufe hier ein."

                              Kommentar

                              Lädt...
                              X