Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33898 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69159 invoked by uid 1010); 10 Dec 2007 16:37:24 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 69144 invoked from network); 10 Dec 2007 16:37:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Dec 2007 16:37:24 -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.224 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.224 nz-out-0506.google.com Received: from [64.233.162.224] ([64.233.162.224:27420] helo=nz-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/C4-37002-34B6D574 for ; Mon, 10 Dec 2007 11:37:24 -0500 Received: by nz-out-0506.google.com with SMTP id x7so544876nzc for ; Mon, 10 Dec 2007 08:37:21 -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:mime-version:content-type; bh=zCDjgU7ZNA4dxx3xWnaY0BVC/AF3u04yTUsuOvkZ3PU=; b=kuAFrxY+I/ATARgWuQ5HTd4rznHcE2fuyVgu/yzNIo0A0MBOQ/iEUQiMh3Bf0spfaCy4oqz+GaIchkxvVxev0R5iUv0qqcb5wH8oXJCxREkViG5pmOlYbqc7MgJhuYlxUAXJa7Gl7kXrp0rdE04xOlX8pNtqWBENtftq5dxRbDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=X2qSiVvZnLEhhXj10kQ32Es43ym3I6ma6vlBmjLCXmRfCPGh5XuqzKUwBfFG5Welcdearm83Ukgn2lkMhSjT3erP1EmIvzqgbj+QyTfy5FCZ8rKZcVsB8YU81k+j/NI1by4SjuJoaGQkfACTLWGesdHT9teMlvO3weriVREWStk= Received: by 10.142.158.17 with SMTP id g17mr3088530wfe.1197304640370; Mon, 10 Dec 2007 08:37:20 -0800 (PST) Received: by 10.142.157.9 with HTTP; Mon, 10 Dec 2007 08:37:20 -0800 (PST) Message-ID: <52dbac0f0712100837m76aeb9b1o8f2ff666451a73a9@mail.gmail.com> Date: Mon, 10 Dec 2007 13:37:20 -0300 To: "PHP Developers Mailing List" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18575_24821064.1197304640363" Subject: RFC: Arguments (and suggestions) against the current implementation of namespaces From: malterisio777@gmail.com ("Martin Alterisio") ------=_Part_18575_24821064.1197304640363 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 1) Lack of cohesiveness of name resolution rules Why is this an argument against: name resolution rules with namespaces change completely the way names are resolved in PHP. How does it affects: this breaks the explicitness of names in PHP. It will affect code debugging and review. Example: Suggestions: a) Introduce a special name to refer to the current namespace (as self:: works for the current class). All namespace access should be explicit: b) Name aliasing with use should only generate namespaces aliases: c) Solve ambiguity generated by using :: as namespace separator (see following argument) ---- 2) Using :: as namespace separator generates ambiguity Why is this an argument against: :: is also used for static member access and becomes ambiguous when used together How does it affects: same as (1). Example: Suggestions: a) find a way to clearly distinguish the namespace part of a name (I've currently no suggestions on what operator to use without seriously harming readability). b) OR restrict the namespace application to classes (if only classes can be namespaced there is no ambiguity, although I must admit I don't like this option). ---- 3) Enforcing a scope is something that has no precedence in the PHP language What: the namespace statement and the import statement (use) has an enforced scope to the file. Why is this an argument against: there was not a construct that works as this one in PHP. How does it affects: it changes the way we work with code. We now how to be conscious of declarations enforced on the whole file, not because we messed up with scopes but because we didn't have a choice. Suggestions: a) Allow the before mentioned statements to have scope managed by the coder. b) Disallow the scopeless use of those statements (which is implicitly scoped to the file). c) If bracketed namespaces are a no-go, consider the possibility of declaring the full name of the namespaced element in its definition: Which should work as: ------=_Part_18575_24821064.1197304640363--