Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54934 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28001 invoked from network); 25 Aug 2011 12:43:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2011 12:43:40 -0000 Authentication-Results: pb1.pair.com header.from=sebastian@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=sebastian@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 93.190.64.36 as permitted sender) X-PHP-List-Original-Sender: sebastian@php.net X-Host-Fingerprint: 93.190.64.36 mail-6.de-punkt.de Received: from [93.190.64.36] ([93.190.64.36:53074] helo=mail-6.de-punkt.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 75/E4-00227-B73465E4 for ; Thu, 25 Aug 2011 08:43:40 -0400 Received: (qmail 6407 invoked by uid 511); 25 Aug 2011 12:43:42 -0000 Received: by simscan 1.3.1 ppid: 6402, pid: 6405, t: 0.0246s scanners: attach: 1.4.0 Received: from unknown (HELO ?0.0.0.0?) (sb%sebastian-bergmann.de@217.114.76.105) by 0 with ESMTPA; 25 Aug 2011 12:43:42 -0000 Message-ID: <4E564378.1030206@php.net> Date: Thu, 25 Aug 2011 14:43:36 +0200 Organization: PHP Development Team User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: internals@lists.php.net References: <4E5619ED.40609@php.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] ReflectionClass::newInstanceWithoutConstructor() From: sebastian@php.net (Sebastian Bergmann) On 08/25/2011 02:39 PM, Etienne Kneuss wrote: > To me this feature makes no sense. But if people find use for it and > it remains in Reflection, I won't object to it, so +0. It should only be used for meta programming, of course ;-) > If an internal class can't behave well without a constructor call, > that should already be fixed/prevented, as it's already possible by > extending it. I second that emotion but as long as those internal classes are not fixed I think it makes sense to disallow creating objects of internal classes without invoking their constructor. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/