Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:34259 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93073 invoked by uid 1010); 26 Dec 2007 21:05:30 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 93058 invoked from network); 26 Dec 2007 21:05:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Dec 2007 21:05:30 -0000 Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 212.25.124.162 mail.zend.com Windows 2000 SP4, XP SP1 Received: from [212.25.124.162] ([212.25.124.162:19984] helo=mx1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 77/B3-56976-912C2774 for ; Wed, 26 Dec 2007 16:05:29 -0500 Received: from us-ex1.zend.com ([192.168.16.5]) by mx1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 23:05:26 +0200 Received: from [192.168.16.90] ([192.168.16.90]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 13:05:23 -0800 Message-ID: <4772C214.10802@zend.com> Date: Wed, 26 Dec 2007 13:05:24 -0800 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Alterisio CC: PHP Developers Mailing List References: <52dbac0f0712252104l37af6feay64797ee8f3c020df@mail.gmail.com> In-Reply-To: <52dbac0f0712252104l37af6feay64797ee8f3c020df@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2007 21:05:23.0060 (UTC) FILETIME=[07A7D340:01C84803] Subject: Re: [PHP-DEV] Sayonara PHP From: stas@zend.com (Stanislav Malyshev) > The use statement behavior currently supports only class names aliasing. > Functions and constants have to referred with full name, although these too > can be namespaced. Right, this was an conscious decision - since there are much more functions than classes, importing functions into global space is much higher risk (and utility functions in OO libraries are less frequently used externally then classes). > resolution rules will bring much headaches to users. For starters you'll > have to make a habit of prefixing :: to all internal function calls (such as > ::count, ::strlen, etc). This way will be safer for creating php libraries, You can do it, but mandating it is not a good idea, which was discussed here. > ---- Constrained scope for imports is unpractical ---- > > When trying to refactor code to use namespaces, as a test, I also found that > having the use statement limited to outer scope is unpractical. One > necessary addition, which is not very complicated, is to have an extra scope > for use statements, such as imports in a function scope. It's only a matter > of keeping an extra table for the function scope in compile time. It would make PHP code more complicated, so I'm not sure it is a good addition. > ---- Namespaces as nested classes? ---- > > Reading about how the previous implementation of namespaces went down the > drain, one recurring though in some users and developers caught my > attention. Maybe namespaces and nested classes should be one and the same > thing in php. Considering that many are using classes as namespaces for The issue of nested classes was discussed numerous times and it never proved to be a good idea. > ---- Type hints, improvements could help drastically improve performance > ---- > > I thought much about type hints. Right now they are only seen as syntactic > sugar for system designers, and something that reduces performance. Actually > quite the opposite can be achieved, but not with the current implementation > of type hinting. The guys behind flash 9 obtained a 10x improvement in > performance thanks to type hinting. Actually doing the same with PHP is > quite sensible, since one of the bottlenecks for performance is the zval. It would be nice to hear what did you mean by that. > Knowing before hand that the variable is a native type, a just in time > native compile can be done to drastically improve performance. I know of no efforts for JIT compiling PHP, so I guess if we'd want to get something there, we'd better start with having any JIT at all and not with modifying the language for possible imaginary JIT compiler. > ---- Taints ---- > > Last but not least, I thought about taints. Since PHP6 will remove safe mode > and magic quotes, as far as I know, if nothing else is there to prevent > users from being users, well PHP6 might be considered too insecure. Taints I must note that the primary reason for removal of "safe mode" and "magic quotes" were the fact that it does not improve security. Thus, PHP 6 is not less secure than any versions with these capabilities. Primary fault of "magic quotes" was that it tried to solve input filtering problem without taking into account how variables are used, better input filtering extension takes care of that. Primary fault of "safe mode" was that it tried to bring into PHP things that can not be properly done in PHP, since PHP engine can not control extensions. > much can be added to zval without suffering the consequences, and a simple > model of tainted/not tainted is not safe enough, as there are many taints to > be considered (XSS, SQL injection, HTML injection to say the least). That's what current proposal is doing. I can not have an opinion of how good it does it since I didn't finish reviewing it yet. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com