Hi,

On Mon, Nov 23, 2015 at 10:30 AM, Rowan Collins <rowan.coll...@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 let
>> 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() which
> 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 returning
> 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…

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) == 'resource'
is_resource($myResource) == true
($myResource instanceof CurlHandler) == true

The only thing I see as contentious, is actually, is_object() — should that
return false, maintaining BC, or true?

Reply via email to