Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19938 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10733 invoked by uid 1010); 9 Nov 2005 23:07:04 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 10718 invoked from network); 9 Nov 2005 23:07:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Nov 2005 23:07:04 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:17907] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 69/EF-28724-71182734 for ; Wed, 09 Nov 2005 18:07:04 -0500 Received: (qmail 23539 invoked from network); 9 Nov 2005 23:06:59 -0000 Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1) by localhost with SMTP; 9 Nov 2005 23:06:59 -0000 Message-ID: <6.2.3.4.2.20051109150622.0379d0a0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 09 Nov 2005 15:06:55 -0800 To: "Thies C. Arntzen" ,internals@lists.php.net Cc: Thies Arntzen In-Reply-To: <6.2.3.4.2.20051109141302.037967b0@localhost> References: <81D9588B-8984-432C-91CB-9ECE28F573F0@thieso.net> <6.2.3.4.2.20051109141302.037967b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] object-overloading: why not allow recursive calls? (5.1) hey, in zend_object_handlers.c function zend_std_read_property we protect against calling the __get function of an object if we're already in a __get() function. (look for From: andi@zend.com (Andi Gutmans) Thies, I think I might be wrong in my analysis. Seems like the problem is worse than what I thought as it seems to cross boundaries between classes. We'll look into it more. Andi At 02:15 PM 11/9/2005, Andi Gutmans wrote: >This is intentional and I think it makes it much more fool-proof for >developers. Adding recursion protection can be very expensive and >complicated, and it doesn't seem to make sense here. The idea is >that once you're in the __get() method, you know exactly how your >properties are mapped and can do the right thing. It's only this one >method where you have your mapping anyway, not an entirely different place. > >Andi > >At 12:35 AM 11/4/2005, Thies C. Arntzen wrote: >>hey, >> >>in zend_object_handlers.c function zend_std_read_property we protect >>against calling the __get function of an object if we're already in a >>__get() function. (look for zobj->in_get) in that function. >> >>i don't think we should be doing this. >> >>simplyfied example: >>>class test { >> function __get($offset) { >> echo "__get($offset)\n"; >> switch ($offset) { >> case 'name': return "name"; >> case 'length': return strlen($this->name); >> } >> } >>} >> >>$a = new test; >>var_dump($a->length); >>?> >> >>outputs: >>__get(length) >>int(0) >> >>but should say: >>__get(length) >>__get(name) >>int(4) >> >>i think recursive gets are highly useful and should be allowed. if we >>really want to protect against recursion (here) we have two real >>options: -a- protect against __get(ing) the same property more than >>once in the same call-chain (mucho work), or -b- (preferred) have >>some global infinite recursion protection in the engine (needs to be >>done somewhen anyhow, but not now). >> >>so, in one sentence: as we don't protect against recustion elsewhere, >>can we please remove this unneded roadblock? >> >>opinions? >>-thies >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php