Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.83.50 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
In-Reply-To: <CAMhKfba+uk=cN3v_gSkc5rkf9MUc06Muv3mQ2bNURiNZ64fcqQ@mail.gmail.com>
Date: Tue, 5 Nov 2013 16:28:19 +0100
Cc: Developers List PHP Mailing <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <29341BBD-F837-42CB-9607-796CCDC4EEE0@googlemail.com>
References: <CAMhKfba+uk=cN3v_gSkc5rkf9MUc06Muv3mQ2bNURiNZ64fcqQ@mail.gmail.com>
To: Oleg Poludnenko <oleg@poludnenko.info>
Subject: Re: [PHP-DEV] PHP RFC: Deffering functions by arguments (count or/and type)
From: ingwie2000@googlemail.com (Kevin Ingwersen)

Hello there.

You can actually do the first part using __call($methodName, array =
$args). It's a little more complex to do that, but consider that as a =
current solution. Alternatively, use func_get_args() inside your =
function, or set the second parameter like method($arg1, $arg2=3Dnull) =
and check if it is, or isn't null using if(is_null($arg2)), and then do =
what the function should return on either scenario. I know, you are =
listing these cases within your list of benefits, but one if is less =
work than having PHP decide which "version" of the function you're =
wanting to use - I bet it'd make the actual runtime slightly slower.

The second part sounds interesting IMHO, but I somehow doubt it'd be =
accepted. But we'll see.

Kind regards, Ingwie
Am 05.11.2013 um 14:03 schrieb Oleg Poludnenko <oleg@poludnenko.info>:

> Hi,
>=20
> My idea is somehow related to this one: Syntax for variadic
> functions<https://wiki.php.net/rfc/variadics>
> It is not a competitive idea but a supplemental one.
>=20
> So, the main point is to write different implementations for the =
functions
> with the same name, but with different of arguments count or/and type:
>=20
> class Config { /** * Returns property value * @param string $key *
> @returnmixed */
> public function prop($key) { return isset($this->prop[$key]) ? =
$this->prop[
> $key] : null; } /** * Sets property value * @param string $key *
> @parammixed $value *@returnConfig */
> public function prop($key, $value) { $this->prop[$key] =3D $value; =
return
> $this; } }
>=20
> Also it will be possible to change arguments during inheritance:
>=20
> class Figure { /** * Calculate perimeter of an arbitrary figure *
> @paramarray $angles *@returnint */
> public function calcPerimeter(array $angles) { return =
array_sum($angles); }
> } class Square extends Figure { /** * Calculate perimeter of a square
> *@paramint $angle *@returnint */
> public function calcPerimeter($angle) { return 4 * $angle; } } class
> Rectangle extends Figure { /** * Calculate perimeter of a rectangle *
> @paramint $height *@paramint $width *@returnint */
> public function calcPerimeter($height, $width) { return 2 * ($height +
> $width); } }
>=20
> The advantages of the syntax are:
>=20
>   - It's immediately clear what function implements.
>   - The function becomes cleaner, without a lot of if-else =
constructions.
>   - A great opportunity to change function arguments during =
inheritance.
>=20
>=20
> Regards,
> Oleg Poludnenko