Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30949
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.146.182 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=qxh2aCOcIHySpY2J+Ee6fj4Zec7xM873hYUCOgAJEXfDAKtYtSP8UBiqyAjrstuzHeBAWCOL2IXurFnjSxmQqzLs5895lxnGQ8VOxTqdBNNWZUsdl/7/Xqu8nEjhMXHA0E01il9vboX3XVWVssFJqURaxLjgYP5bpFfKbCelHv4=
Message-ID: <3d1a63d10707150624y2b166f33y1bf3f628aba596b2@mail.gmail.com>
Date: Sun, 15 Jul 2007 16:24:29 +0300
To: internals@lists.php.net
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: RE: [PHP-DEV] Simple Namespace Proposal
From: d.giedrius@gmail.com ("Giedrius D")

Hi,

I read whole discussion and I'd like to share my opinion.

> > Similarly, allowing multiple namespaces per file does not limit the
> > developer in any way. Not allowing them does. I always thought a
> > language should be designed to empower it's developers, not get in
> > their way.
>
> My opinion is that sometimes language *should* "get in the way" - if the
> developer is trying to do a wrong thing. Doing things right should be
> easy, doing things wrong should be hard. I agree that this means we
> should choose some definitions for right and wrong, and not everybody
> would necessarily agree, but I think the benefit of the clearer program
> structure exceeds the disadvantage of not being able to do some tricks.
> That's one of the reasons why PHP doesn't have some things that other
> languages might have, such as nested classes, multiple inheritance or
> closures.

I agree with Andrew Minerd. Language shouldn't get in developers way.
If its too
hard to implement then let it be. Most developers can live with that I
guess. However if
the only reason for this is so called "clearer program structure" then
I don't think
this limit is reasonable. There's no such thing as absolutely "wrong
thing to do".
The thing that is "wrong thing to do" in one situation may be a "good
thing to do" in
other. One size *does not* fit all.


The other thing that bothers me is namespaces nesting. It was said
that namespaces
nesting is not supported. Then I'm missing a point in having namespace
named "A::B".
Lets say I have three files:

a.php:
<?php
namespace A;

function foo()
{
}
?>

b.php:
<?php
namespace A::B;

function bar()
{
    //foo();
}
?>

index.php:
<?php
require 'a.php';
require 'b.php';

import A;
foo(); // should call A::foo(), right?
B::bar(); // will this call A::B::bar()?
?>

If this works then we have a nested namespace here. The only thing
that's missing is
[commented] foo() call in A::B::bar() to be correctly resolve to
A::foo() as now it would
resolve to built-in function foo() if I understand it correctly.

Now if this does not work then whats the point in having namespace
"A::B" instead of "A_B"? IMHO this brings more confusion then
clearness.


Regards,
Giedrius