Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89336
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.160.179 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <5653310E.406@gmail.com>
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>
Date: Mon, 23 Nov 2015 11:17:39 -0500
Message-ID: <CANaX5nfGQtDJ2r_7Jmmsoinj8G06m9dNGe6ny3_-3Pn3i7iguQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114fac2869a5920525379030
Subject: Re: [PHP-DEV] Re: Resource typehint and return type
From: davey@php.net (Davey Shafik)

--001a114fac2869a5920525379030
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Nov 23, 2015 at 10:30 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Ben Scholzen 'DASPRiD' wrote on 23/11/2015 01:57:
>
>> On 13.11.2015 12:59, Bob Weinand wrote:
>>
>>> The alternative is replacing the resources by proper objects, without
>>> methods and public properties.
>>> Then we could integrate it into our object hierarchy in a very
>>> lightweight way with proper typing.
>>>
>>> Having special syntax doesn't really improve it much...
>>>
>>> Bob
>>>
>>
>> I just looked at this again, and I don't know how I could miss this for
>> so long, but we already have SplFileObject. Wouldn't it make sense to le=
t
>> fopen() and complementary functions use that?
>>
>>
> I believe the blocker on just rushing to convert existing resources into
> objects is that there are functions like is_resource() and getttype() whi=
ch
> will start behaving differently.
>
> Functions which accept a resource as a parameter could easily be extended
> to accept either a resource or an object, but anything currently returnin=
g
> a resource cannot be changed without declaring a breaking change. And if
> you're changing fgets but not fopen, you might as well just build a new
> API, which SplFileObject already has most of (for some reason, it appears
> to include fputcsv but not fputs).
>
> Regards,
> --
> Rowan Collins
> [IMSoP]


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=E2=80=A6

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.

But I would definitely prefer to see a CurlResource or ImageResource object
instead of a resource type hint. Think:

class CurlResource implements Resource { }
function makeRequest(CurlResource $curl) { }
function serializeResource(Resource $resource) { }
gettype($myResource) =3D=3D 'resource'
is_resource($myResource) =3D=3D true
($myResource instanceof CurlHandler) =3D=3D true

The only thing I see as contentious, is actually, is_object() =E2=80=94 sho=
uld that
return false, maintaining BC, or true?

--001a114fac2869a5920525379030--