2013/2/25 Nils Andre <nilsan...@gmail.com> > 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") { ... } >
Must say, that for now I didn't read your mail completely, but this example is .. it doesn't fit. The problem is, that you compare two different semantics. function startsWith($string, $startsWith) { return !strncmp($string, $startsWith, strlen($startsWith)); } $b->startsWith('This'); startsWith($b, 'This'); Now they aren't that different anymore. > > 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. > No: strlen($string) > > == 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. > -- github.com/KingCrunch