Hello, See the reply inline:
On Mon, Feb 25, 2013 at 3:43 PM, Nils Andre <nilsan...@gmail.com> wrote: > 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. Follow the steps described here in order to get RFC karma and everything should be fine: https://wiki.php.net/rfc/howto :) > == 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. I'm not very comfortable with the autoboxing of --everything--. Could you please detail why autoboxing anything that's not array or string would be useful? I like the idea of autoboxing for strings / arrays, where the most problems related to parameters order would be solved but for the other types, as a developer I can't see it. > > 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. This should be done in a transparent manner imho. The current substr function should be mapped to String::substr() as well. I'd recommend you play a bit with this: https://github.com/nikic/scalar_objects and come up with some examples on how the classes would look like before going forward with this proposal. > == 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. IIRC disabling functionality via ini settings isn't a desired thing. As for namespaces I think it's a bad idea. Currently everything in PHP is global, not namespace and this introduces a new layer for programmers to learn of. > == 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. Currently I'm playing around with a demo implementation of this feature but it's private at the moment, still in early stages. I'd be happy to work on and provide a patch for this later on. Currently all the RFCs should be targeted for PHP-next (5.6) so there's no rush for this imho. Have a nice day ---- Florin Patan https://github.com/dlsniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
