Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33763 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54471 invoked by uid 1010); 5 Dec 2007 19:56:24 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 54431 invoked from network); 5 Dec 2007 19:56:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Dec 2007 19:56:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=sam@sambarrow.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=sam@sambarrow.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain sambarrow.com from 205.234.132.11 cause and error) X-PHP-List-Original-Sender: sam@sambarrow.com X-Host-Fingerprint: 205.234.132.11 scottsdale.servershost.net Received: from [205.234.132.11] ([205.234.132.11:58821] helo=scottsdale.servershost.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8C/F1-20707-26207574 for ; Wed, 05 Dec 2007 14:56:20 -0500 Received: from [65.207.49.92] (port=47997) by scottsdale.servershost.net with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1J00Lu-0003tM-0j; Wed, 05 Dec 2007 13:56:14 -0600 To: Jochem Maas Cc: PHP Developers Mailing List In-Reply-To: <4756F740.3060800@iamjochem.com> References: <4755FB31.2050901@zend.com> <4756E3AF.2070703@zend.com> <4756EC80.1070500@iamjochem.com> <4756F146.3050306@zend.com> <4756F740.3060800@iamjochem.com> Content-Type: text/plain Date: Wed, 05 Dec 2007 14:56:08 -0500 Message-ID: <1196884568.19096.4.camel@sbarrow-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scottsdale.servershost.net X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sambarrow.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PHP-DEV] Namespace From: sam@sambarrow.com (Sam Barrow) I didn't put any work in here and I agree with him 100%. Namespaces have been incredibly useful for me. Now that I'm using them I would not want to do without them. As far as bundling, my application (over 11,000 lines now) did use a bundling feature that I can no longer use. It would be very nice to be able to do this, but honestly it is worth the performance hit to me. Any large application needs structure, and yes underscores can be used but this is a pain typing out long names every time, and what's the harm? If you want to use bundling or don't like namespaces then just don't use them. On Wed, 2007-12-05 at 20:08 +0100, Jochem Maas wrote: > Stanislav Malyshev wrote: > >> +1 for putting namespaces on the backburner and taking the time to > >> get it 100% right ... > > > > What's "100% right"? Any proposals (besides braces)? > > I'll take a guess that you put alot of effort into the namespace implementation, > that's the only reason I can think of that your taking it all so personally and > being rather vitriol. > > for the sake of your health take a step back and breath my friend. you are > not the car you drive, the clothes you wear or the namespace implementation you > created :-) > > > > >> apparently people keep 'flogging this horse to death' because they are > >> not > >> convinced by your wisdom with regard to this decision - they may be > >> idiots (me included) > > > > I never talked about "idiots". I know smart people can have different > > opinions, and - oh horror! - some may have wrong or mistaken opinions > > too, and that doesn't make them idiots. How about you? > > it was a self effacing comment. I think it's safe to say that compared to > most of the php devs, I, and people like me could be considered idiots at > least as far as developing is concerned .. it's all relative besides which > the key words were "may be". > > > > >> actually that is not true - a halfbaked concept is pretty much > >> garanteed to give you > >> and the users of your product more headaches than no implementation at > >> all. and > > > > This concept, however, is not "halfbaked". > > based on the reactions it has been recieving I would disagree. that is not to say > that completing the baking process would not result in a wonderful functional addition > to the language. I'm just advocating putting it on the backburner until the cooking > time is complete. > > "halfbaked" is probably the wrong word - it has negative conatations that I didn't > mean to imply. > > > > >> besides possibly having to type a little less, there seems to be > >> nothing namespaces would > >> give us [in it's current form] that we cannot achieve already ... with > >> the bonus that > > > > Yes there is. More structured and clean code. > > you have metrics to back that up? of course not because it's a completely subjective > point of view - and many people seem to think that there is no real gain in this respect, > besides there is nothing to stop me writing namespaced spaghetti. > > I agree that namespaces pontentially offer a tool that allows developers to create > clearer structure in their code but given that it's only a potential why not take a time > out to hammer out more details, get more consensus and work out the details of where > namespacing should go in terms of functionality with the hassle of having to worry about BC. > > > > >> conversly - when namespace functionality is released, every developer > >> will be confronted > >> with any problems they might bring with them, at some stage, because > >> there will be third > >> party code out there that uses namespaces (code which for the sake of > >> argument one would > >> be required to use under some circumstances). > > > > These problems being? > > no longer having the option of bundling files for performance reasons is one example, personally > I have never done anything like that but apparently other people do and with positive results for > their applications - to me it seems that forcing such a restriction on these people is against the > pragmatic philosophy that [hopefully still] drives php, and is rather artificial. >