It's a good idea, IMHO. This particular paragraph should probably be removed:
"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."
The problem with this paragraph is that you are comparing apples to
oranges. If PHP wanted a starts_with function, it could add one
without autoboxing. Stick to benefits that are achieved specifically
by autoboxing.
It's also possible to achieve consistency without autoboxing. You
could introduce:
str_substr
str_begins_with
str_find
Et cetera, et cetera, and always put the haystack first, and you would
have consistency.
However the OOP syntax forces you to be consistent, at least about the
"first argument" (which, with autoboxing, becomes the object you are
invoking a "method" upon). And this is a good thing because it reduces
the risk of inconsistencies creeping in.
Also, the OOP syntax that you're using for the other half of your code
and with which developers are already comfortable from other
languages.
I think it's important to make these points in the RFC, and avoid
issues that can be addressed equally well without autoboxing such as
your substr() example.
On Mon, Feb 25, 2013 at 8:43 AM, 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.
>
> == 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.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
