Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36991
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>,
 internals Mailing List <internals@lists.php.net>
Message-ID: <9E248AAC-8BD6-4331-82F0-A0EA383A2B0F@pooteeweet.org>
To: karlstrk@arcada.fi
In-Reply-To: <47FB4531.4030605@arcada.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sun, 13 Apr 2008 12:06:37 +0200
References: <1207539695.5736.42.camel@pena>	 <8d7b8c130804062157j60871630r6c3b27c4d3245cb9@mail.gmail.com>	 <alpine.DEB.0.98.0804071543580.4652@kossu.ez.no>	 <1207576676.5331.49.camel@felipe> <47FA507D.2070108@cschneid.com>	 <10845a340804071346m251eae49j907b4a6ca7c607be@mail.gmail.com>	 <47FA94B2.6050704@cschneid.com>	 <9b3df6a50804080202n456fc08blfef3e70034d95c1c@mail.gmail.com>	 <47FB3830.2080907@arcada.fi> <9b3df6a50804080305i3bff79b4n7237ebb0be70db4@mail.gmail.com> <47FB4531.4030605@arcada.fi>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.135, required 6, AWL 0.04, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] Return type hints
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 08.04.2008, at 12:13, Krister Karlstr=F6m wrote:
> Yes indeed you can implement it using the __call method, but it =20
> would be more readable if the language structure itself would =20
> support it. I suggested this just because I think that this is the =20
> most common way of using overloading, thus this probably would make =20=

> sense to lot of users out there.

I think polymorphism is exactly the opposite from easier to read. For =20=

the bulk of functions I will never need it (even if I am a type hint =20
lover) and so by default I now have to look for all variations of a =20
single method instead of knowing its either that one or its in =20
__call() (well there is also inheritance, but lets now make it any =20
harder for this fairly rare case). This is all a solution to a problem =20=

we do not have (but are trying to get with type hints)/

>>> I think type hint's would be good optional functionality. Those =20
>>> who need
>>>> will use it, others will not. I'd probably use it in some cases.
>>>> Especially
>>>> if named parameters are implemented.
>>>>
>>>> Sometimes what I really want is named parameter pass like
>>>>
>>>> function myfunc(array $array, string $string =3D null, int $someint =
=20
>>>> =3D 0){
>>>> }
>>>>
>>>> myfunc($myArray, someint =3D $mySomeInt);

Named parameters I see as much more useful, though I generally think =20
that there are ways to ensure that the number of parameters stays =20
small enough to not make named parameters necessary.

regards,
Lukas=