Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89343 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4390 invoked from network); 23 Nov 2015 19:07:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Nov 2015 19:07:39 -0000 Authentication-Results: pb1.pair.com header.from=mail@dasprids.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mail@dasprids.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain dasprids.de from 46.4.80.198 cause and error) X-PHP-List-Original-Sender: mail@dasprids.de X-Host-Fingerprint: 46.4.80.198 server1.dasprids.de Received: from [46.4.80.198] ([46.4.80.198:42618] helo=mail.dasprids.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/C8-47837-9F363565 for ; Mon, 23 Nov 2015 14:07:38 -0500 Received: from [192.168.0.86] (unknown [5.158.132.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@dasprids.de) by mail.dasprids.de (Postfix) with ESMTPSA id EF9F934401FF for ; Mon, 23 Nov 2015 20:07:33 +0100 (CET) To: internals@lists.php.net References: <56429DAB.6010005@dasprids.de> <56455965.60101@gmail.com> <5645C1E9.8000206@php.net> <5652728F.5060201@dasprids.de> <5653310E.406@gmail.com> Message-ID: <56536407.9080702@dasprids.de> Date: Mon, 23 Nov 2015 20:07:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5653310E.406@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Resource typehint and return type From: mail@dasprids.de (Ben Scholzen 'DASPRiD') On 23.11.2015 16:30, Rowan Collins 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. There's another blocker: the SplFileObject currently has no fclose() method, which should definitely be implemented. Currently it relies on being destroyed to close the internal resource. In case of cross references, there's no way to explicitly close the file handle. May I suggest to implement fclose() in SplFileObject for now to bring it in line with the plain functions? I'd say that when fclose() was called on an SplFileObject and e.g. an fwrite(), fread() or the like call is made on the object, it throw's an exception? -- Ben Scholzen 'DASPRiD' Community Review Team Member | mail@dasprids.de Zend Framework | http://www.dasprids.de