Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28792 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10736 invoked by uid 1010); 13 Apr 2007 16:01:02 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 10721 invoked from network); 13 Apr 2007 16:01:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Apr 2007 16:01:01 -0000 Authentication-Results: pb1.pair.com smtp.mail=andrei@gravitonic.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=andrei@gravitonic.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain gravitonic.com from 204.11.219.139 cause and error) X-PHP-List-Original-Sender: andrei@gravitonic.com X-Host-Fingerprint: 204.11.219.139 mail.lerdorf.com Received: from [204.11.219.139] ([204.11.219.139:46762] helo=mail.lerdorf.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 74/72-26709-A39AF164 for ; Fri, 13 Apr 2007 12:01:00 -0400 Received: from [66.228.175.145] (borndress-lm.corp.yahoo.com [66.228.175.145]) (authenticated bits=0) by mail.lerdorf.com (8.13.8/8.13.8/Debian-3) with ESMTP id l3DG0oNF011904; Fri, 13 Apr 2007 09:00:50 -0700 In-Reply-To: <461EB95D.7030603@zend.com> References: <461E4437.2090105@pooteeweet.org> <461E5674.5010107@hristov.com> <461EB95D.7030603@zend.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: Cc: Andrey Hristov , Lukas Kahwe Smith , internals@lists.php.net Content-Transfer-Encoding: 7bit Date: Fri, 13 Apr 2007 09:02:45 -0700 To: Stanislav Malyshev X-Mailer: Apple Mail (2.752.2) Subject: Re: [PHP-DEV] PHP6 todo list From: andrei@gravitonic.com (Andrei Zmievski) Yes, if we have persistent zvals we can use objects/arrays as properties or constants for internal classes. I asked for this 2.5 years ago. -Andrei On Apr 12, 2007, at 3:57 PM, Stanislav Malyshev wrote: > Well, actually persisting zvals between requests would be very > problematic since it can not then use regular memory allocator > (which is cleaned up at the request end). Which means the engine > must know which allocator allocated the variable, otherwise we'd > get a lot of trouble when mixing such variables in the same context. > Also, it's not clear for me what such variable could be used for. I > see only two potential uses: > 1. Persistent resources. You don't really need zval then - persist > the resource and allocate zval on need. Resources are refcounted > separately, so no problem. > 2. Caching. Here one would be much better to use external (with > regard to the engine) caching solution - persisting zval would not > gain that much since it's still limited to the process (which may > not be either accessible or alive next time you need it) and > overhead of converting regular zval to persistent one would be > roughly the same as overhead for serializing zval into some form of > cache. So I'd leave this to extensions. > Are there any other reasons for persistent zvals? > -- > Stanislav Malyshev, Zend Products Engineer > stas@zend.com http://www.zend.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php