Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66191
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEC7-PTF-UmKnfOMGjkw5oGh3YGM0pftT3aF8c1XrraJU9Tttg@mail.gmail.com>
References: <CAEC7-PTF-UmKnfOMGjkw5oGh3YGM0pftT3aF8c1XrraJU9Tttg@mail.gmail.com>
Date: Mon, 25 Feb 2013 16:19:01 +0200
Message-ID: <CAA9esyTRRwn0FhYb1zVu-CFTSaRRL9i0ziVe3xJqnVUbyVFRYw@mail.gmail.com>
To: nilsandre@gmx.de
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC Autoboxing Draft
From: florinpatan@gmail.com (Florin Razvan Patan)

Hello,

See the reply inline:

On Mon, Feb 25, 2013 at 3:43 PM, Nils Andre <nilsandre@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