Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72749
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.179 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <5307B1FE.1020604@marc-bennewitz.de>
References: <5307B1FE.1020604@marc-bennewitz.de>
Date: Fri, 21 Feb 2014 21:13:13 +0000
Message-ID: <CAGAGxbZQ7xg2rgjnijz95+1w6nWU+H3FVJsJyyOh0mNH7tZckw@mail.gmail.com>
To: Marc Bennewitz <php@marc-bennewitz.de>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [php6] OOP resources
From: daverandom@php.net (Chris Wright)

On 21 February 2014 20:07, Marc Bennewitz <php@marc-bennewitz.de> wrote:
> Hi,
>
> here another idea for PHP 6 the simply means removing the datatype
> "resource" because and convert current resources into classes/objects
> as it's already done with GMP.
>
> Because resources are simply a pointer to a somewhere described data
> structure - resources are the exactly the use case for objects.

I'm a big fan of this idea in principle, resources have always struck
me as just a messier way of dealing with objects. However, to go
through every usage of the resource type an convert them is a mammoth
task, because I don't there being any point in doing it unless the
procedural APIs that use them are given an OO overhaul. The vast
majority of the time they are used in the context of
`<resource_purpose_prefix>_action_name($resource, ...$args)`, and if
they were converted to objects a `$resource->action_name()` method is
what I would expect. The procedural APIs could still be maintained,
much like MySQLi.

I don't see the goal of completely removing the resource type as being
practical or, considering how many PECL and custom extensions this
would affect, sensible. However, I'd be all for a general push to
convert/duplicate as many core resource-oriented APIs as possible to
OO APIs.

> To be bc current resources should be instances of an interface
> "Resource" and the function "is_resource" would work similar as
> "$resource instanceof Resource".

And, more importantly, it will become a lot easier (in many cases,
simply "possible") to determine what a "resource" is actually for. In
reality is_resource() isn't hugely useful, I can't call fwrite() on a
stream context resource, for example.