Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72799
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain marc-bennewitz.de from 80.237.132.171 cause and error)
Message-ID: <530B9D10.5010409@marc-bennewitz.de>
Date: Mon, 24 Feb 2014 20:27:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Chris Wright <daverandom@php.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <5307B1FE.1020604@marc-bennewitz.de> <CAGAGxbZQ7xg2rgjnijz95+1w6nWU+H3FVJsJyyOh0mNH7tZckw@mail.gmail.com>
In-Reply-To: <CAGAGxbZQ7xg2rgjnijz95+1w6nWU+H3FVJsJyyOh0mNH7tZckw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [php6] OOP resources
From: php@marc-bennewitz.de (Marc Bennewitz)


Am 21.02.2014 22:13, schrieb 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.
Shouldn't it be possible to change the internal resource macros to
generate objects of a specified class unter the hood?

>
>> 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.
>