Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
To: Davey Shafik <davey@php.net>
References: <56429DAB.6010005@dasprids.de> <AA.FC.21426.A26A2465@pb1.pair.com>
 <56455965.60101@gmail.com> <5645C1E9.8000206@php.net>
 <DUB406-EAS34425BB831BCA9E75F44BDE2110@phx.gbl>
 <5652728F.5060201@dasprids.de> <5653310E.406@gmail.com>
 <CANaX5nfGQtDJ2r_7Jmmsoinj8G06m9dNGe6ny3_-3Pn3i7iguQ@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <56533FF7.60808@gmail.com>
Date: Mon, 23 Nov 2015 16:33:59 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CANaX5nfGQtDJ2r_7Jmmsoinj8G06m9dNGe6ny3_-3Pn3i7iguQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: Resource typehint and return type
From: rowan.collins@gmail.com (Rowan Collins)

Davey Shafik wrote on 23/11/2015 16:17:
>
> How is this a breaking change? The only way you can get a resource, or 
> resource-object is from a function that currently returns a resource 
> (e.g. imagecreate()), and you can't do anything with a resource except 
> pass into things that expect resources. If instead they return an 
> object, and every function that currently expects a resource now 
> expects that kind of resource-object, it could just work…

Within those functions, it's fine, but there are a handful of "meta" 
functions which can tell the difference between a resource and an 
object, and these may be used in existing code for error handling or 
switching behaviour - e.g.

switch ( gettype($file) )
{
case 'string':
// code to open a new handle
break;
case 'resource':
// code to use the open handle
break;
case 'object'
if ( $file instanceOf MyFileWrapperInterface ) // ...
break;
default:
// error
}


> Would it be possible to create a (possibly empty, but maybe useful) 
> interface that all of the new resource-objects implement, meaning 
> is_resource() and gettype() can check for that going forward and 
> return a BC result (and if necessary, leave the current implementation 
> in there as a code path for custom extensions maybe). You could also 
> type hint off that interface, either transparently replacing the 
> proposed type hint, or instead of.

This certainly helps, but you've still got to break something, because 
currently is_resource() and is_object() are mutually exclusive, and 
gettype() can only return one string, so you've got to break somebody's 
code somewhere. (Cue xkcd "every change breaks somebody's flow" comic; 
but I think the example above demonstrates that this is a non-trivial 
break.)

> But I would definitely prefer to see a CurlResource or ImageResource 
> object instead of a resource type hint.

Definitely agree here.

> The only thing I see as contentious, is actually, is_object() — should 
> that return false, maintaining BC, or true?

I think it would be weird not to have it return true - otherwise in 10 
years time, there'd be a weird note in the manual saying 
"is_object($var): returns true if $var is an object, unless it is one of 
the following internal types..." gettype() returning 'resource' for an 
object would be similarly surprising.

More contentious is how is_resource() should behave; assuming *all* 
resources are converted, it could just be deprecated anyway, I guess...

Regards,
-- 
Rowan Collins
[IMSoP]