Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=PGQSFSgEd4g8HwgmAsNOdCOnZEu5jM/iQ0o7awZcanX/K4zuleAUHgGxlQX5ZcyMhK
         EoBs34q0UhCzpQis3S8qwV8LHXxgyC7GakKaLuaXU+gF3BLY4CacG0xQ51VIHmRIWNEJ
         vqtpy3gQT1GiIfoT3E3haoowg+ES4PwXz52RI=
MIME-Version: 1.0
In-Reply-To: <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>
	<3046FEA7-AC12-4211-9DBD-C28E5E0C27E4@gmail.com>
Date: Thu, 28 Apr 2011 15:05:02 -0300
Message-ID: <BANLkTi=uZVP4oofVKGrbA3n0tR2pyw=D5w@mail.gmail.com>
To: Matt Wilson <shadda@gmail.com>
Cc: Internals Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6d26dc5751c1d04a1fe6533
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: martinscotta@gmail.com (Martin Scotta)

--0016e6d26dc5751c1d04a1fe6533
Content-Type: text/plain; charset=ISO-8859-1

 Martin Scotta


On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson <shadda@gmail.com> wrote:

> 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.
>

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.

That's why I always thought that NULL meant "no value".

function foo(Foo $f1, Foo $f2=null) {
   // $f1 can't be null
   // $f2 can be null
}


> 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.
>
> 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?
>
> 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.
>
> +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!
> >
> >> 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
> >
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e6d26dc5751c1d04a1fe6533--