Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.43 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <29BDF40C-562D-4943-877B-70701335D3AA@ajf.me>
References: <CAMauByXxg877TEhQiSWSRkJR-wYvP+pm=mLHK9=9N05t2SiUmw@mail.gmail.com>
	<03CFE6C6-0742-4928-BD2B-E9C920E9246A@ajf.me>
	<CAMauByUz=rUYwdMcZi5+_wSUBcV_KRiMZs0foL5ZyDxwKxh-6Q@mail.gmail.com>
	<29BDF40C-562D-4943-877B-70701335D3AA@ajf.me>
Date: Sat, 8 Mar 2014 23:01:28 +0000
Message-ID: <CAGAGxbbVuMcH+bYJuw20NUScuOTbxqfC6m=G2JsnEKQyYvtByQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Marco Schuster <marco+php@m-s-d.eu>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Idea: ifdef-like feature to ease userland BC
From: daverandom@php.net (Chris Wright)

On 8 March 2014 22:33, Andrea Faulds <ajf@ajf.me> wrote:
>
> On 8 Mar 2014, at 21:48, Marco Schuster <marco+php@m-s-d.eu> wrote:
>> This breaks if you use new syntax features like the array shortcut
>> $var=[];, traits or similar.
>
>
> Right, but those aren't problems. I can't see anyone willingly writing:
>
>     #ifdef PHP_5_4
>     $a = [1,2,3];
>     #else
>     $a = array(1,2,3);
>     #endif
>
> They will simply write:
>
>     $a = array(1,2,3);
>
> For traits, again, it's unlikely people will want to write two sets of code and deliberately duplicate things. They'll simply just not use traits.
>
> The only case where what you're saying makes sense is where features are removed in favour of alternatives, and I can't see that happening for any syntactic features.
>
> --
> Andrea Faulds
> http://ajf.me/
>

I'm not necessarily in favour of this idea as a core feature but to
give a more practical example of how this could be useful: generators
can give considerable efficiency gains where previously more resources
would have been consumed by a process yielding values over time.
Before 5.5, generator code would cause a parse error.

Imagine the following somewhat contrived example:

function some_func() {
    $fp = fopen('some_file.ext');
    $result = array();
    while (false !== $line = fgets($fp)) {
        $result[] = $line;
    }
    return $result;
}

foreach (some_func() as $foo) {
    // do stuff
}

Imagine that some_func() is only ever used in the context of a
foreach. For BC reasons, we have to keep this API. Since 5.5, we could
use a generator (yes, we could use an iterator, I said it was
contrived :-P), but we need to provide BC with older PHP versions:

function some_func() {
    $fp = fopen('some_file.ext');
#if PHP_VERSION >= 5.5.0
    while (false !== $line = fgets($fp)) {
        yield $line;
    }
#else
    $result = array();
    while (false !== $line = fgets($fp)) {
        $result[] = $line;
    }
    return $result;
#endif
}

As another example, imagine a heavy data processing routine that uses
goto for performance reasons, but before 5.3 would fall back to using
private methods instead:

#if PHP_VERSION >= 5.3.0
private function partOfRoutine()
#else
partOfRoutine:
#endif
{
    /* stuff */

#if PHP_VERSION >= 5.3.0
    anotherPartOfRoutine();
#else
    goto anotherPartOfRoutine;
#endif
}

Another advantage for performance-minded people is that a
pre-processor is a one-shot deal, whereas runtime checks are
potentially performed a few hundred times a second with the exact same
result every time for ever more.

**However** the thought occurs that, while potentially useful, a
pre-processor of this nature could easily be done with a userland
implementation, a composer dependency and a composer
after-install/after-update script...

Thanks, Chris