Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52066
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=SD2+9pKt5KjTNYQ4B7a1Oj7R8clOtz4nqzrgLnBWJOSuAGTmMo3PlrkJwavNaud+yL
         bVwYdTGiiRwVWXlcQ8HQRKCMVIMG0rLLnQmbM5qEYcwuVP6j0r/j0h30CXyiDiaNuf9U
         ZsxjzsFLc1sTRZeNqjU9tHDGwi8FXaFELp0/Q=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
In-Reply-To: <4DB9A5A2.2080208@sugarcrm.com>
Date: Thu, 28 Apr 2011 12:51:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <3046FEA7-AC12-4211-9DBD-C28E5E0C27E4@gmail.com>
References: <AANLkTimDdM4Udx53qW8jU4NuP3kU8+vmU6y4ZgXRVn+X@mail.gmail.com> <BANLkTinMW_iqqOPJCuLnCB+-VEKxapPdGg@mail.gmail.com> <4DB923E6.3020307@sugarcrm.com> <4DB925D4.5090107@thelounge.net> <4DB926B4.5000307@sugarcrm.com> <20110428085859.GJ8496@phcomp.co.uk> <4DB936C8.2080801@lerdorf.com> <20110428095958.GM8496@phcomp.co.uk> <4DB9A5A2.2080208@sugarcrm.com>
To: Internals Mailing List <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: shadda@gmail.com (Matt Wilson)

Here's my issue:

We're borrowing a feature from strongly typed languages and forcing it =
on a loosely typed language. I'm fine with this, if we're true to the =
concept.

In a regular language, if you type something to return an object of type =
Foo, you might still get back null, and appropriately need to check for =
this. NULL is a perfectly valid state for an object.

The objection I'm hearing to this is that because in PHP, null is a =
value and not a state, and since variables don't have types (values do), =
null should be an explicitly specified hint.=20

To me, this is a nuclear bomb waiting to go off. If we allow the syntax =
described earlier (Foo | Bar | Null) we're violating the concept =
entirely, and there's no point in even having the feature. If a =
developer can type hint a function in such a way that you don't actually =
know what you're getting besides a subset of types, this has the exact =
opposite effect that return hinting is supposed to have. Now, I have to =
check for what type the value returned is, on top of null. Why even use =
return hinting?=20

The other suggestion I've heard is to only allow for Object || Null, but =
this too seems ridiculous. The idea would be that if you're in a =
situation where you can't feasibly return the specified object, you =
should throw an exception. So now your code is going to be riddled with =
things like ObjectIsNullException, or generic handlers that don't know =
what to do besides go "OOPS!" when this happens. OR, you force default =
values down your object's throats. This is bad when the object you're =
using is volatile, and writes to a database or something.

The complain is that implicitly allowing null returns means you have to =
check for null even if you're expecting an object. But *you have to do =
this anyway* if you're not hinting.=20

+1 for return type hinting
-1 for explicitly specifying null
-100000000 for specifying multiple return types


On Apr 28, 2011, at 12:36 PM, Stas Malyshev wrote:

> Hi!
>=20
>> There will also be advantages for HipHop which can afford to spend =
the time to
>> do static analysis of code -- I know that HipHop is not your baby
>> but you now need to recognise that there is more than one PHP =
implementation
>> and features that may not had much advantage with Zend may be useful =
elsewhere.
>=20
> If you want a statically typed language, there are tons of these on =
the market. However, unless you change PHP into another - statically =
typed - language, I do not see how it really helps.
> What you talking about here is creating a dialect of PHP targeted for =
statically-compiled environment. I personally see it a bit pointless, =
since there are already many perfectly good static languages on the =
market, with excellent compilers and environments - so why not use any =
of these? But that shouldn't deter you - my personal opinion is just =
that, if you want to create your own static PHP, go ahead. But I do not =
believe doing it in little tweaks would work - if you want reliable =
typing, you need it everywhere.
>=20
> However, I seriously doubt PHP as a whole would benefit from it. Most =
uses of PHP are very dynamic and would not yield serious benefits from =
introducing static typing constructs beyond very specific cases in very =
specific environments. Changing the whole language to benefit these =
narrow scenarios does not seem beneficial to me.
> --=20
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20