Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66186
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
Reply-To: nilsandre@gmx.de
Date: Mon, 25 Feb 2013 14:43:47 +0100
Message-ID: <CAEC7-PTF-UmKnfOMGjkw5oGh3YGM0pftT3aF8c1XrraJU9Tttg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307f3aa8f6212c04d68cba78
Subject: RFC Autoboxing Draft
From: nilsandre@gmail.com (Nils Andre)

--20cf307f3aa8f6212c04d68cba78
Content-Type: text/plain; charset=ISO-8859-1

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.

--20cf307f3aa8f6212c04d68cba78--