Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33904 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22294 invoked by uid 1010); 10 Dec 2007 18:53:27 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 22278 invoked from network); 10 Dec 2007 18:53:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Dec 2007 18:53:26 -0000 Authentication-Results: pb1.pair.com header.from=malterisio777@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=malterisio777@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.235 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: malterisio777@gmail.com X-Host-Fingerprint: 64.233.162.235 nz-out-0506.google.com Received: from [64.233.162.235] ([64.233.162.235:22375] helo=nz-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 36/8C-37002-52B8D574 for ; Mon, 10 Dec 2007 13:53:26 -0500 Received: by nz-out-0506.google.com with SMTP id x7so603476nzc for ; Mon, 10 Dec 2007 10:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=JfREFaWJukGvecmY8JtirfAoL2y9Tt/uz88N/Xajr/0=; b=WUzniOvIr1S/VFGnDMsur47UQzDrq+t8N+ItraL1q9YbfqjcpcsRuuOCTIWBIcqRMWQt6tVPDDZLIcmnvu9TBUF7Ie1tBxRVSX5GFydZlziy07FQocEvXBDDyXv48OsdbxTJlCHjg0LRADTup9rHh+/kkh/WHycwQUu4Vjx4hFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LSiZUO5Vx4Hq+DARqCWNyKlLhN4zyoA1+9l6ic/Pwkv9MNsVxSt5XHYAu9rHTiMWZ4kbPVqvU7aUk+2UrG6lqWEuNQuqi3u59l6ws6NyxQ0ZTiHrEpwH43E8PLOaTDhHaxc2W5HZIl0eOO4pMjbKrjN1aUmAV0DFzNKdcZNKzpQ= Received: by 10.142.222.21 with SMTP id u21mr3212094wfg.1197312802222; Mon, 10 Dec 2007 10:53:22 -0800 (PST) Received: by 10.142.157.9 with HTTP; Mon, 10 Dec 2007 10:53:22 -0800 (PST) Message-ID: <52dbac0f0712101053k31b06733u6bbc9d3d38806a8a@mail.gmail.com> Date: Mon, 10 Dec 2007 15:53:22 -0300 To: "Stanislav Malyshev" Cc: "PHP Developers Mailing List" In-Reply-To: <475D78D4.6050509@zend.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19205_6182114.1197312802220" References: <52dbac0f0712100837m76aeb9b1o8f2ff666451a73a9@mail.gmail.com> <475D78D4.6050509@zend.com> Subject: Re: [PHP-DEV] RFC: Arguments (and suggestions) against the current implementation of namespaces From: malterisio777@gmail.com ("Martin Alterisio") ------=_Part_19205_6182114.1197312802220 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2007/12/10, Stanislav Malyshev : > > > All namespace access should be explicit: > > Consequence: nobody uses namespaces, as it's too annoying. Putting $this-> and self:: is annoying , that didn't stop anybody from using objects in PHP. > b) Name aliasing with use should only generate namespaces aliases: > > See no reason for that limitation. Used in moderation, class aliasing is > OK. Main thing is not to rely on it for everything. Maybe, but then I'll suggest that these aliases are accessed through namespace:: or similar. > 2) Using :: as namespace separator generates ambiguity > > Would that be 20th reincarnation of "let's find weirdest namespace > separator" thread? :) Please no. Just find the right one. > > ... > > Foo::test(); // a member function? a namespaced function? > > ?> > > Sometimes you need context. When you just take $foo->bar() it doesn't > give you much - you should know what $foo is and what bar() does. But you still know that $foo->bar is a member function call. That information only makes code review and debugging a lot easier. The current implementation of namespaces introduces a lot of uncertainty. I do not need to tell you how hard and time consuming it is to debug or review C++ code. I beg you, please do not make PHP a language that's as harder to debug or review. And even if you say "sometimes you need context", be prepared to be asked "why now?". Why context was not applied inside a class definition? Why do I have to use $this-> or self::? Why is there no with ($object) { ... } ? > Why is this an argument against: there was not a construct that works as > > this one in PHP. > > This is not an argument - each construct works as needed for it to work > to achieve its purpose. So, every construct of a language works as a distinct unit? There's no need to keep cohesiveness with how other constructs behave? We'll have to accept that now there'll be statements that enforces a scope? No problem then, I'll start training my brain to remember the namespaces and imports of each file. Maybe it makes sense in a language like Java that also enforces a directory structure, but PHP? > c) If bracketed namespaces are a no-go, consider the possibility of > > declaring the full name of the namespaced element in its definition: > > Which would lead to people routinely mixing different namespaces inside > one file. Bad idea. Also would kill namespaced functions and constants, > which would make organizing libraries using those impossible. Why would it lead to people routinely mixing different namespaces inside one file? Why is this bad in the first place? Why is it the language the one to decide which is the better way to organize code? Also, that would not kill neither namespaced functions nor constants: ------=_Part_19205_6182114.1197312802220--