Re: Re: Resource typehint and return type
| From: | Rowan Collins | Date: | Mon, 23 Nov 2015 15:30:22 +0000 |
| Subject: | Re: Re: Resource typehint and return type | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-89334@lists.php.net to get a copy of this message | ||
Ben Scholzen 'DASPRiD' wrote on 23/11/2015 01:57:
On 13.11.2015 12:59, Bob Weinand wrote: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]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... BobI 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?