Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89173
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5642A801.3050909@dasprids.de>
References: <56429DAB.6010005@dasprids.de>
	<AA.FC.21426.A26A2465@pb1.pair.com>
	<5642A801.3050909@dasprids.de>
Date: Wed, 11 Nov 2015 11:28:36 +0100
Message-ID: <CAF+90c9n9Sg6vaaHm0UtcyeQmkk7JHFGwyu3nYh536-gYsmOcQ@mail.gmail.com>
To: "Ben Scholzen 'DASPRiD'" <mail@dasprids.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113eb39606961a0524414aa7
Subject: Re: [PHP-DEV] Re: Resource typehint and return type
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113eb39606961a0524414aa7
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 11, 2015 at 3:29 AM, Ben Scholzen 'DASPRiD' <mail@dasprids.de>
wrote:

> On 11.11.2015 03:21, Andrea Faulds wrote:
>
>> The reason for this is that the resource type is an anachronism from an
>> age in which PHP did not have objects, yet still needed to make certain
>> types of data opaque. The resource type is a type that exists only to
>> shuffle around C pointers between internal functions. It has no semantic
>> value. Because resources are now redundant, given the existence of
>> objects, their time is running out, and they will be replaced at some
>> point. Adding a type declaration for resource would mean that code using
>> it would break if we replace any existing usage of resources with
>> objects, preventing migration away from resource.
>>
>
> I see, I didn't really know about this. Although right now, we still use
> resources to pass around the fopen() pointers. Do you mean that it is
> planned to have a read/write object like we have in e.g. Python (supplied
> by the open() function)?
>

The long term plan is to do transitions similar to the one which GMP
underwent: It uses GMP objects since PHP 5.6 and was using resources
previously. The API is still the same (procedural), but we could now add an
additional object-oriented one as well.

Before this transition can happen comprehensively, we will have to add
support for persistent objects.

In addition to what Andrea said (resource type hint causing issues should
we choose to migrate to objects), I also think that the resource type hint
provides relatively little value in itself. It only says that you are
accepting *some* resource. However, resources are many. Is this a file
handle? Is it a database connection? Is it a streaming hash context? It
doesn't tell.

"resource" would be the analogue of an abstract "object" typehint (rather
than a specific class/interface hint), which notably we do not have either
-- the cases where it would be useful, i.e. the cases where you are working
on *arbitrary* objects (or resources) are relatively few.

Nikita

--001a113eb39606961a0524414aa7--