Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33860 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58584 invoked by uid 1010); 8 Dec 2007 01:00:22 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 58569 invoked from network); 8 Dec 2007 01:00:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Dec 2007 01:00:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.17 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 76.96.30.17 qmta10.emeryville.ca.mail.comcast.net Received: from [76.96.30.17] ([76.96.30.17:41721] helo=QMTA10.emeryville.ca.mail.comcast.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5F/90-51565-5ACE9574 for ; Fri, 07 Dec 2007 20:00:22 -0500 Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id MtWW1Y00C0QkzPw0A0ip00; Sat, 08 Dec 2007 01:00:21 +0000 Received: from earth.ufp ([71.228.13.89]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id N10L1Y0021vH2xB0800000; Sat, 08 Dec 2007 01:00:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=3oOEpAiQkl5zv8RkAlkA:9 a=Xce7FswyxrwtBAvmh7cA:7 a=RSx5Wxu56htkO9dU6AX64EPQKXoA:4 a=FHBbIDN7CdwA:10 a=LY0hPdMaydYA:10 Received: from localhost (localhost [127.0.0.1]) by earth.ufp (Postfix) with ESMTP id 608E5D8342 for ; Fri, 7 Dec 2007 19:00:14 -0600 (CST) Received: from earth.ufp ([127.0.0.1]) by localhost (earth.ufp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi440IWQmNTs for ; Fri, 7 Dec 2007 19:00:11 -0600 (CST) Received: from vulcan.ufp (vulcan.ufp [192.168.42.4]) by earth.ufp (Postfix) with ESMTP id B957AD8341 for ; Fri, 7 Dec 2007 18:59:59 -0600 (CST) To: internals@lists.php.net Date: Fri, 7 Dec 2007 19:01:01 -0600 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <1197060932.28351.31.camel@sbarrow-desktop> <1197061767.14915.108.camel@blobule> In-Reply-To: <1197061767.14915.108.camel@blobule> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200712071901.01888.larry@garfieldtech.com> Subject: Re: [PHP-DEV] Namespace From: larry@garfieldtech.com (Larry Garfield) On Friday 07 December 2007, Robert Cummings wrote: > On Fri, 2007-12-07 at 15:55 -0500, Sam Barrow wrote: > > Very good point > > > > namespace stuff ; > > { > > function myfunction() { > > return true ; > > } > > } > > > > That would actually work, but it's not quite the same as you have the > > semicolon after the namespace declaration, which looks kind of stupid. > > Overall i dont think braces are a bad idea. > > > > People say multiple namespaces per file are confusing, but braces would > > partially solve this. If using braces makes multiple namespaces per file > > more likely, I say that's the way to go, as I am very much in favor of > > multiple namespaces per file. > > As I've said previously, I'm neutral to the namespace thing. I imagine > I'll realize advantages in the future, but given that I try to keep my > code backward compatible until the death of a version, I don't think > I'll be using them until about 2012. However, having said that, I would > also have to say I'm in the braces camp. The above example while > perfectly valid, is an obvious hack and throws a little WTF factor at > anyone viewing it :) Probably silly thought that I am going to throw out anyway: I've seen three different arguments for braces over a bare keyword: 1) Visually easier to read. 2) More logical for multiple namespaces per file (relates to #1). 3) Easier for code-assistance programs to pick up and make use of in various ways. The arguments against that I've seen are: 1) It makes the engine a bit slower. (I will take the word of the C coders on that one.) 2) Multiple namespaces per file is a bad thing, don't encourage it. 3) It supposes nested namespaces, which this isn't. (Although as Greg pointed out, you can effectively use them almost that way anyway.) Ignoring points #2 for the moment, the main pro-brace arguments come down to usability, both human and IDE. As the last few posters in this thread have pointed out, random braces are a no-op to the compiler as long as they balance so if one is so inclined. So aside from a weird-looking semi-colon, we can visually have our cake and eat it too with a common coding convention of: namespace Foo; { ... } To the compiler, it's a keyword. To the reader, it's a brace with an extra semi-colon in it. I've only played with the tokenizer a little bit, but would that also be sufficient meta-data for code-assistance programs (vim, Zend, Eclipse, Komodo, or whatever) to do their magic, much the same as @return Foo in phpDoc can be used to code-complete objects returned from a function/method? That would, I think, involve no changes to the engine. It would be strictly a documented trick in the manual somewhere. "PHP only cares about the keyword. A common convention for extra visual clarity is to wrap the body of the namespace in un-tagged braces. Although the compiler ignores them, some IDEs may make use of them for improved code assistance." Or something like that. That is, of course, predicated on the extra braces actually having no effect on the parser or compiler. Thoughts? -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson