Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 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 14:59:58 +0100
Message-ID: <CALtuQzCEHV0yjQN5=NPyj-PbNYNKnt=0FMHdp_MwqGKB5f__5A@mail.gmail.com>
To: nilsandre@gmx.de
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044287f214609a04d68cf6b6
Subject: Re: [PHP-DEV] RFC Autoboxing Draft
From: krebs.seb@gmail.com (Sebastian Krebs)

--f46d044287f214609a04d68cf6b6
Content-Type: text/plain; charset=ISO-8859-1

2013/2/25 Nils Andre <nilsandre@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

--f46d044287f214609a04d68cf6b6--