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?