On Wed, Nov 11, 2015 at 3:29 AM, Ben Scholzen 'DASPRiD' <m...@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
