Hi Everyone on the list, I have no RFC Karma here so far, so I post this to the list at first. There has been ongoing discussion about new APIs and so fort, so this is a suggestion for language cleanup by Autoboxing. I'd really appreciate comments.
== Introduction == This RFC tries to approach the need for Autoboxing in PHP, or, to make primitive types behave as if they were objects when being used or accessed in an objectional fashion. Autoboxing can be discussed from various perspectives, which is far beyond the scope of this document, which much more addresses the fact that the language of PHP must be cleaned up in order to grow more in terms of maturity and hence, in user accpetance. == Autoboxing in brief == Autoboxing is that we can use primitive types, like integers, strings, booleans and array as if they were objects, but without being constructed as objects themselves. Autoboxing is widely discussed, and somehow a must-have in OOP as a consequence to having primitive types (for the sake of performance and memory overhead) but keeping the language OOP-consistent. == Why PHP needs it == PHP needs autoboxing as a means to restructure the language and make it more predictable. One big flaw of today's PHP is, that it is unstructured and chaotic with its builtin functions, as, for example, those dealing with strings. Not going too much into details here, many programmes always have to look up the function definition because very similar functions have their parameters in different orders or simply don't act in a predictive, well-structured manner. This article is a good read to sum it up: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ The problem derives from the fact that PHP has not been designed top-down, but has been developed the bottom-up way over many years: As of today, the language offers features other languages don't have, but struggles with it's buried bodies from the past (mainly because compatibility had and still has to be kept.) By _adding autoboxing_ for all primitive types (Booleans, Strings, Integers, Arrays), we would clean up the language in a very consistent manner, but still retain backwards compatibility. == How it could be implemented == We would not need much programming, because we simply map the new autoboxed notation to the old code. We suggest the new notation to reproduce the Java notation and parameter sequence closely, because it is pretty straightforward and consistent (see, for example, the Javadocs on java.lang.String). == Syntax == The mapping is very straigtforward. Consider this: $a = "This is a string"; $b = $a->toUpperCase() --> $b = ucase($a) $b = $a->substring(0,4) --> $b = substr($a, 0, 4) It would also allow many brilliant constructs like the following if ($b->startsWith("This")) { ... } in contrast to if (substr($b,0,4) == "This") { ... } Notice that the latter is error-prone, because if the condition changes one would always have to match the string on the right handside to the length of it on the left. == Compatibility == The old notation could be switched on/off at any time. The old notation would be switched on by default until, say, PHP 6, and can then be enabled/disabled by either a compile flag, INI setting or some "use \PHP5\*;" or something on top of a PHP file, which then makes the old notation available to any code that follows/any file that is included afterwards. As a consequence, \PHP5 will be the namespace comprising all "old"/compatibility stuff. == Advantages == - Cleanup of the language - Consistency and predictability improved a lot (also in constrast to possible userland classes - which would then all be slightly different) - No lacking backwards compatibility - Easier learning for new PHP programmers (beginners to PHP would be much more pointed to learning OOP than procedural programming) - Easier switching for programmers from Java to using PHP and vice versa (now that PHP grew very mature, attract the Java folks with the cool stuff PHP offers) - Little overhead (as far as I am aware) to implement - Nicer language syntax (see References) == Disadvantages == - I don't know how complicated it is to implement. So far we don't have any extensions for this on PECL, except for strong typing (see reference). From a theoretical point of view, it is just mapping. - There might be heaps of ways to implement, as the other autoboxing RFC offers one possiblity. Certainly we need discussion on the best way to implement. Maybe also "autoboxing" is the wrong word, as this RFC simply suggests to map primitive types to some objectual syntax. == References == This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of nicer syntax. [[ http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and-indestructable-objects-english-version/]] implements a sort of userland "autoboxing" in PHP. [[http://www.php.net/manual/en/intro.spl-types.php]] is the documentation of PECL SPL_Types, which make strongly-typed classes for primitive types available. While they implement strong typing (if wanted), they do not offer syntax cleanup.
