Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37681 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33869 invoked from network); 16 May 2008 15:44:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 May 2008 15:44:55 -0000 Authentication-Results: pb1.pair.com header.from=sv_forums@fmethod.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=sv_forums@fmethod.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error) X-PHP-List-Original-Sender: sv_forums@fmethod.com X-Host-Fingerprint: 69.16.228.148 unknown Linux 2.4/2.6 Received: from [69.16.228.148] ([69.16.228.148:44609] helo=host.fmethod.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A0/9F-00945-4FBAD284 for ; Fri, 16 May 2008 11:44:53 -0400 Received: from [83.228.56.37] (port=3334 helo=pc) by host.fmethod.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jx26z-0006fy-M3 for internals@lists.php.net; Fri, 16 May 2008 10:44:50 -0500 Message-ID: <2DA61F1F6DB245F5A628540F51AAE45F@pc> To: "internals Mailing List" References: <482B9F96.7050908@gmail.com> <482CE5F8.5000700@gmail.com> <4D.AE.00945.5066D284@pb1.pair.com> <482D9F66.4000802@chiaraquartet.net> Date: Fri, 16 May 2008 18:44:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.fmethod.com X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - fmethod.com Subject: Re: [PHP-DEV] Re: 5.3 Namespace resolution rules suggestions From: sv_forums@fmethod.com ("Stan Vassilev | FM") Hi, I'd like to nudge the discussion back to issues with the resolution rules that we're discovering :) The actual char(s) used can only be mildly annoying to some (at worst), compared. Can we please agree on those (or explain why you'd not): 1) functions, constants and classes should use the same resolution rules. Making special cases just for some of them, or just for user or just internal ones will lead to confusion. 2) can someone please explain why is it useful to override internal function inside a namespace. Isn't it better to explicitly refer to global functions as global, which would allow compile-time resolution in a lot more cases than now. I said before, it looks like the current situation where you can define globally a PHP-only clone of a missing binary/internal features is a far more predictable behaviour, and people use it a *lot* right now. Do we really want to break this in 5.3? Regards, Stan Vassilev >>> is it too late to scrap all this and go with Java/AS3 style >>> base.package.class please? >> >> yes > > Not saying that it is a good thing to do that but it is not too late > to change things. > > Cheers, > -- > Pierre