Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65684 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84503 invoked from network); 5 Feb 2013 23:55:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2013 23:55:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=alan@akbkhome.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=alan@akbkhome.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender) X-PHP-List-Original-Sender: alan@akbkhome.com X-Host-Fingerprint: 202.81.246.113 akbkhome.com Received: from [202.81.246.113] ([202.81.246.113:41465] helo=akbkhome.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/F0-11820-0EB91115 for ; Tue, 05 Feb 2013 18:55:13 -0500 Received: from wideboyhd ([192.168.0.28]) by akbkhome.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Mailfort v1.2) (envelope-from ) id 1U2sM0-0006Y9-0q for internals@lists.php.net; Wed, 06 Feb 2013 07:55:08 +0800 Message-ID: <51119BDA.9070805@akbkhome.com> Date: Wed, 06 Feb 2013 07:55:06 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: internals@lists.php.net References: <1460659e-237d-4c7c-8cfa-523ec857d646@email.android.com> <51074873.5090600@roojs.com> <51076233.2040507@sugarcrm.com> <5109A834.6070503@roojs.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------080204070005030005030907" X-mailfort-sig: 54dd502ef10549ea4674041406ef992f Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (with patch) From: alan@akbkhome.com (Alan Knowles) --------------080204070005030005030907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Attached should be a patch to illustrate the exception. (obviously needs some tests modified, or created) This removes the warning in the single situation where the calling scope and target scope share the same top level parent. eg. Traits without the baggage... I think this is a reasonable change, It removes a warning which is only partly true. In this small exception, It enables the language to behave more like a scripting language, where yes, we do frequently have the possibility of incompatible types, but only emits hints and notices when they are really helpful and accurate. Hopefully this means I can finally turn E_STRICT warnings on. Regards Alan On Thursday, January 31, 2013 07:41 PM, Ferenc Kovacs wrote: >> The fact that this use of PHP is documented in the manual as a feature >> www.php.net/manual/en/**language.oop5.basic.php >> >> And mentions that it will elicit a E_STRICT error - does not indicate that >> it would be DEPRECATED, I'm assuming that has been documented for years, >> and only recently (a year or two) has the E_STRICT comment been added. >> There is also no real Justification for the E_STRICT message = see >> suggestion at end.. >> > I stand corrected, I said that (AFAIR) is an undocumented feature, but as > you pointed out, it is documented since (at least) 2004: > http://svn.php.net/viewvc/phpdoc/en/trunk/language/oop5/basic.xml?view=markup&pathrev=166424 > (there is a typo here, so it is called a psudo variable) > And an example was added in 2005: > http://svn.php.net/viewvc?view=revision&revision=178495 by sean (funny > commit comment: 'document seemingly-odd $this behaviour'). > The E_STRICTs were added to the examples in 2009: > http://svn.php.net/viewvc?view=revision&revision=288217 > > This doesn't really change my opinion, but it means that there could be > more people using this feature than I/we assumed. > Given the fact that this already spits E_STRICT(and E_STRICT is part of > E_ALL since 5.4) and both E_STRICT and E_DEPRECATED is disable in > our php.ini-production, I would say that changing this from E_STRICT to > E_DEPRECATED has no direct impact to the userland. > But we can use this change to sample the people using this feature and > based on the feedback we can decide whether we want to keep this or remove > it for the next version. > So my opinion is that we should stick to the vote and deprecate this > feature but update the RFC and remove the part removing it in the next > version. > --------------080204070005030005030907 Content-Type: text/plain; charset=UTF-8; name="incompatible_context.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="incompatible_context.txt" ZGlmZiAtLWdpdCBhL1plbmQvemVuZF92bV9kZWYuaCBiL1plbmQvemVuZF92bV9kZWYuaApp bmRleCAyN2IyYmQxLi5jNmZjZGNiIDEwMDY0NAotLS0gYS9aZW5kL3plbmRfdm1fZGVmLmgK KysrIGIvWmVuZC96ZW5kX3ZtX2RlZi5oCkBAIC0yNTkxLDEyICsyNTkxLDIwIEBAIFpFTkRf Vk1fSEFORExFUigxMTMsIFpFTkRfSU5JVF9TVEFUSUNfTUVUSE9EX0NBTEwsIENPTlNUfFZB UiwgQ09OU1R8VE1QfFZBUnxVTlVTCiAJCSAgICAhaW5zdGFuY2VvZl9mdW5jdGlvbihaX09C SkNFX1AoRUcoVGhpcykpLCBjZSBUU1JNTFNfQ0MpKSB7CiAJCSAgICAvKiBXZSBhcmUgY2Fs bGluZyBtZXRob2Qgb2YgdGhlIG90aGVyIChpbmNvbXBhdGlibGUpIGNsYXNzLAogCQkgICAg ICAgYnV0IHBhc3NpbmcgJHRoaXMuIFRoaXMgaXMgZG9uZSBmb3IgY29tcGF0aWJpbGl0eSB3 aXRoIHBocC00LiAqLwotCQkJaWYgKGNhbGwtPmZiYy0+Y29tbW9uLmZuX2ZsYWdzICYgWkVO RF9BQ0NfQUxMT1dfU1RBVElDKSB7Ci0JCQkJemVuZF9lcnJvcihFX1NUUklDVCwgIk5vbi1z dGF0aWMgbWV0aG9kICVzOjolcygpIHNob3VsZCBub3QgYmUgY2FsbGVkIHN0YXRpY2FsbHks IGFzc3VtaW5nICR0aGlzIGZyb20gaW5jb21wYXRpYmxlIGNvbnRleHQiLCBjYWxsLT5mYmMt PmNvbW1vbi5zY29wZS0+bmFtZSwgY2FsbC0+ZmJjLT5jb21tb24uZnVuY3Rpb25fbmFtZSk7 Ci0JCQl9IGVsc2UgeworCQkgICAgIAorCQkJemVuZF9jbGFzc19lbnRyeSAqdG9wX2NlID0g Y2U7CisJCQkKKwkJCWlmICghKGNhbGwtPmZiYy0+Y29tbW9uLmZuX2ZsYWdzICYgWkVORF9B Q0NfQUxMT1dfU1RBVElDKSkgewogCQkJCS8qIEFuIGludGVybmFsIGZ1bmN0aW9uIGFzc3Vt ZXMgJHRoaXMgaXMgcHJlc2VudCBhbmQgd29uJ3QgY2hlY2sgdGhhdC4gU28gUEhQIHdvdWxk IGNyYXNoIGJ5IGFsbG93aW5nIHRoZSBjYWxsLiAqLwogCQkJCXplbmRfZXJyb3Jfbm9yZXR1 cm4oRV9FUlJPUiwgIk5vbi1zdGF0aWMgbWV0aG9kICVzOjolcygpIGNhbm5vdCBiZSBjYWxs ZWQgc3RhdGljYWxseSwgYXNzdW1pbmcgJHRoaXMgZnJvbSBpbmNvbXBhdGlibGUgY29udGV4 dCIsIGNhbGwtPmZiYy0+Y29tbW9uLnNjb3BlLT5uYW1lLCBjYWxsLT5mYmMtPmNvbW1vbi5m dW5jdGlvbl9uYW1lKTsKIAkJCX0KKwkJCQorCQkJd2hpbGUgKHRvcF9jZS0+cGFyZW50KSB0 b3BfY2UgPSB0b3BfY2UtPnBhcmVudDsKKwkJCQorCQkJLyogaWYgY2FsbGluZyBzY29wZSBh bmQgdGFyZ2V0IHNjb3BlIHNoYXJlIHRoZSBzYW1lIHBhcmVudCwgZG8gbm90IHNob3cgd2Fy bmluZyAqLworCQkJaWYgKCFpbnN0YW5jZW9mX2Z1bmN0aW9uKFpfT0JKQ0VfUChFRyhUaGlz KSksIHRvcF9jZSBUU1JNTFNfQ0MpKSAKKwkJCQl6ZW5kX2Vycm9yKEVfREVQUkVDQVRFRCwg Ik5vbi1zdGF0aWMgbWV0aG9kICVzOjolcygpIHNob3VsZCBub3QgYmUgY2FsbGVkIHN0YXRp Y2FsbHksIGFzc3VtaW5nICR0aGlzIGZyb20gaW5jb21wYXRpYmxlIGNvbnRleHQiLCBjYWxs LT5mYmMtPmNvbW1vbi5zY29wZS0+bmFtZSwgY2FsbC0+ZmJjLT5jb21tb24uZnVuY3Rpb25f bmFtZSk7CisJCQl9ICAKIAkJfQogCQlpZiAoKGNhbGwtPm9iamVjdCA9IEVHKFRoaXMpKSkg ewogCQkJWl9BRERSRUZfUChjYWxsLT5vYmplY3QpOwo= --------------080204070005030005030907--