Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49557 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72624 invoked from network); 2 Sep 2010 16:04:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2010 16:04:19 -0000 X-Host-Fingerprint: 78.142.172.145 gate-g21.inqnet.at Received: from [78.142.172.145] ([78.142.172.145:21572] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D3/A4-40118-10BCF7C4 for ; Thu, 02 Sep 2010 12:04:17 -0400 Message-ID: To: internals@lists.php.net Date: Thu, 02 Sep 2010 18:04:12 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Lanikai/3.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 78.142.172.145 Subject: zend_register_class() overwrites ce->create_object with parent_ce->create_object? From: mike@php.net (Michael Wallner) If I define a descendant class, I *obviously* know what create_object should do, as this should only effect internal classes. So could anybody please explain to me why the parent's create_object is enforced? It causes to write hacks like: ---8<--- zend_class_entry *ce; zend_object_value (*__create_object)(zend_class_entry *ce TSRMLS_DC); INIT_CLASS_ENTRY(ce, "classname", php_my_method_entry); ce.create_object = php_my_object_new; /* hack starts here */ __create_object = parent_ce->create_object; parent_ce->create_object = php_my_object_new; php_my_class_entry = zend_register_internal_class_ex(&ce, parent_ce, NULL TSRMLS_CC); parent->create_object = __create_object; --->8--- If this limitation is there without a really good reason, I'd like to get rid of it. Thanks, Mike