Kommentare zu: Wir brauchen echte Typen und keine Primitiven, oder? https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/ Wed, 19 Dec 2018 08:31:45 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Von: digilist https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/comment-page-1/#comment-2481 digilist Thu, 06 Jan 2011 08:23:55 +0000 http://blog.ebene7.com/?p=2408#comment-2481 Solange ich nicht $string = "foobar" schreiben kann, und daraus automatisch ein Objekt wird, macht das ganze auch nicht wirklich Spaß. Das wird doch fast exponentiell mehr Tipparbeit oO Solange ich nicht $string = “foobar” schreiben kann, und daraus automatisch ein Objekt wird, macht das ganze auch nicht wirklich Spaß. Das wird doch fast exponentiell mehr Tipparbeit oO

]]> Von: Fabian https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/comment-page-1/#comment-2477 Fabian Wed, 05 Jan 2011 09:44:48 +0000 http://blog.ebene7.com/?p=2408#comment-2477 In der SPL gibt es eine experimentelle Erweiterung, die PHP um Klassen für primite Typen erweitert, inkl. Enum. Für Arrays gibt es mittlerweile ArrayObject. Ansonsten schließe ich mich Rod an. - http://de.php.net/manual/en/book.spl-types.php In der SPL gibt es eine experimentelle Erweiterung, die PHP um Klassen für primite Typen erweitert, inkl. Enum. Für Arrays gibt es mittlerweile ArrayObject. Ansonsten schließe ich mich Rod an.

- http://de.php.net/manual/en/book.spl-types.php

]]> Von: Rodney Rehm https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/comment-page-1/#comment-2476 Rodney Rehm Wed, 05 Jan 2011 09:23:57 +0000 http://blog.ebene7.com/?p=2408#comment-2476 Ihr habt da etwas missverstanden. Was ihr wollt: OOP-Style auf primitive Datentypen (String, Array, Boolean, Integer, …) zugreifen. Das will man aus zwei Gründen: 1. Endlich mit der Parameterreihenfolge bei String- und Array Funktionen aufräumen. »Wo war $needle? wo war $haystack?«. Simplifiziert die API, macht das Arbeiten angenehmer. 2. $string->slice(0,10)->toUpperCase() ist angenehmer zu lesen als strtoupper(substr($string,0,10)) Was ihr aber nicht wollt, ist das diese Prmitiven auch im Speicher als Objekte vorliegen. Das würde dem RAM vermutlich gar nicht mal so gut bekommen. Davon abgesehen arbeiten sämtliche PHP-core Funktionen direkt mit den primitiven. Man müsste zu viel code anfassen. Momentan wirft $notAnObject->foo eine Notice, $notanObject->bar() einen Fatal Error. Man hat also zwei wunderbare Angriffspunkte, um bei Bedarf einen "auto cast" oder "implicit cast" zu machen. Man erhielte sich so übrigens auch die volle backward compatibility. Grüße, Rod Ihr habt da etwas missverstanden. Was ihr wollt: OOP-Style auf primitive Datentypen (String, Array, Boolean, Integer, …) zugreifen. Das will man aus zwei Gründen:

1. Endlich mit der Parameterreihenfolge bei String- und Array Funktionen aufräumen. »Wo war $needle? wo war $haystack?«. Simplifiziert die API, macht das Arbeiten angenehmer.
2. $string->slice(0,10)->toUpperCase() ist angenehmer zu lesen als strtoupper(substr($string,0,10))

Was ihr aber nicht wollt, ist das diese Prmitiven auch im Speicher als Objekte vorliegen. Das würde dem RAM vermutlich gar nicht mal so gut bekommen. Davon abgesehen arbeiten sämtliche PHP-core Funktionen direkt mit den primitiven. Man müsste zu viel code anfassen.

Momentan wirft $notAnObject->foo eine Notice, $notanObject->bar() einen Fatal Error. Man hat also zwei wunderbare Angriffspunkte, um bei Bedarf einen “auto cast” oder “implicit cast” zu machen. Man erhielte sich so übrigens auch die volle backward compatibility.

Grüße,
Rod

]]> Von: Fabian https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/comment-page-1/#comment-2475 Fabian Wed, 05 Jan 2011 08:19:57 +0000 http://blog.ebene7.com/?p=2408#comment-2475 Sehe ich genauso, allerdings muss ich zugeben dass ich selbst auch schon der Versuchung erlegen bin, eine String-Klasse nach Java-Vorbild zu basteln, mittlerweile verzichte ich wieder darauf, genauso wie auf so fancy hacks wie primitive type hinting¹ und autoboxing², ich freue mich zwar immer wenn ich sehe, was alles möglich ist aber leider geht das immer zu Lasten der Kompatibilität... ¹) http://www.phpclasses.org/package/4195-PHP-Implement-type-hinting-support-for-base-PHP-types.html ²) http://www.phpclasses.org/package/6570-PHP-Wrap-string-and-integer-values-in-objects.html Sehe ich genauso, allerdings muss ich zugeben dass ich selbst auch schon der Versuchung erlegen bin, eine String-Klasse nach Java-Vorbild zu basteln, mittlerweile verzichte ich wieder darauf, genauso wie auf so fancy hacks wie primitive type hinting¹ und autoboxing², ich freue mich zwar immer wenn ich sehe, was alles möglich ist aber leider geht das immer zu Lasten der Kompatibilität…

¹) http://www.phpclasses.org/package/4195-PHP-Implement-type-hinting-support-for-base-PHP-types.html
²) http://www.phpclasses.org/package/6570-PHP-Wrap-string-and-integer-values-in-objects.html

]]> Von: Norbert Bartels https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/comment-page-1/#comment-2474 Norbert Bartels Wed, 05 Jan 2011 07:45:48 +0000 http://blog.ebene7.com/?p=2408#comment-2474 Mach doch Ruby ;) Ich fände es gut, wenn es eine Objektalternative zu den Primitiven gäbe. Neben der Tatsache, dass man - insbesondere bei Strings - viele Methoden direkt am Objekt findet, kann man das type Hinting mehr nutzen (naja vielleicht gibt es das auch mal für Primitive) und würde IDEs unterstützen, da die Auflösung leichter fiele. Auf der anderen Seite würde man, vor allem bei Zahlen, auch ein Autoboxing benötigen, damit bspw. eine einfache Addition nicht übermäßig komplex würde. Übrigens würde ich versuchen eine String-Klasse so zu gestalten, dass diese projektweit nutzbar ist. Aber wenn ich da an die Serialisierbarkeit denke ... Mach doch Ruby ;)

Ich fände es gut, wenn es eine Objektalternative zu den Primitiven gäbe. Neben der Tatsache, dass man – insbesondere bei Strings – viele Methoden direkt am Objekt findet, kann man das type Hinting mehr nutzen (naja vielleicht gibt es das auch mal für Primitive) und würde IDEs unterstützen, da die Auflösung leichter fiele.

Auf der anderen Seite würde man, vor allem bei Zahlen, auch ein Autoboxing benötigen, damit bspw. eine einfache Addition nicht übermäßig komplex würde.

Übrigens würde ich versuchen eine String-Klasse so zu gestalten, dass diese projektweit nutzbar ist. Aber wenn ich da an die Serialisierbarkeit denke …

]]> Von: Timo Reitz https://blog.ebene7.com/2011/01/05/wir-brauchen-echte-typen-und-keine-primitiven-oder/comment-page-1/#comment-2473 Timo Reitz Wed, 05 Jan 2011 07:39:50 +0000 http://blog.ebene7.com/?p=2408#comment-2473 Dazu braucht es gar keine anderen Entwickler: Die gesamte PHP-Klassenbibliothek benutzt die PHP-eigenen Strings. Das Gleiche gilt natürlich für Booleans, Numbers, usw. ebenfalls. Wenn man also nicht gerade halb PHP wrapped (wrappt?), kommt es immer wieder zu Reibungen, wo man dann die primitiv typisierten „Dinge“ (Objekte sind es ja gerade nicht) umwandeln muss. Dazu braucht es gar keine anderen Entwickler: Die gesamte PHP-Klassenbibliothek benutzt die PHP-eigenen Strings. Das Gleiche gilt natürlich für Booleans, Numbers, usw. ebenfalls. Wenn man also nicht gerade halb PHP wrapped (wrappt?), kommt es immer wieder zu Reibungen, wo man dann die primitiv typisierten „Dinge“ (Objekte sind es ja gerade nicht) umwandeln muss.

]]>