Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:mime-version:content-type:from:in-reply-to:date:cc
         :message-id:references:to:x-mailer;
        b=S5LA2+2IfWddIM6y5guwu7ouduDsik8OcR/KGR/f8wjDnAVSJ0Jru18JlzHMVMVhua
         mxhqPsl2Ae93Q/EIVHZv0wyosl1O5INhwBtjcqoIZzgSl46Cbvpq7VDmm4LJ+Bz3u5si
         J/PlaD1smfXEnzqqCKS3PUmWwJUOBaX6mnXNA=
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-10--710615512
In-Reply-To: <BANLkTi=uZVP4oofVKGrbA3n0tR2pyw=D5w@mail.gmail.com>
Date: Thu, 28 Apr 2011 13:08:18 -0500
Cc: Internals Mailing List <internals@lists.php.net>
Message-ID: <176B6382-91A4-43EA-BC10-52DADDFE53EA@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> <3046FEA7-AC12-4211-9DBD-C28E5E0C27E4@gmail.com> <BANLkTi=uZVP4oofVKGrbA3n0tR2pyw=D5w@mail.gmail.com>
To: Martin Scotta <martinscotta@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: shadda@gmail.com (Matt Wilson)

--Apple-Mail-10--710615512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Right, that's what null means. The difference in php is only in =
implementation -- you actually just made my point :)=20

The only reason to have explicit null hints is if you get hung up on the =
whole issue of how php actually implements NULL. The concept is "non =
value", distinct from "empty". The implementation in php is slightly =
difference, since you're not actually working with, say, a null pointer.=20=



On Apr 28, 2011, at 1:05 PM, Martin Scotta wrote:

>=20
>  Martin Scotta
>=20
>=20
> On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson <shadda@gmail.com> wrote:
> Here's my issue:
>=20
> 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.
>=20
> 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.
>=20
> Probably core folks may know how this works better than me but I think =
that null is not an object, scalar or anything at all. It just means the =
absence of value.
>=20
> That's why I always thought that NULL meant "no value".
>=20
> function foo(Foo $f1, Foo $f2=3Dnull) {
>    // $f1 can't be null
>    // $f2 can be null
> }
>=20
>=20
> 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.
>=20
> 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
>=20
>=20
> On Apr 28, 2011, at 12:36 PM, Stas Malyshev wrote:
>=20
> > Hi!
> >
> >> 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.
> >
> > 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.
> >
> > 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.
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20


--Apple-Mail-10--710615512--