Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39946
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.183 as permitted sender)
DomainKey-Status: bad
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:content-transfer-encoding:content-disposition
         :references;
        b=vv66xPMzsWWxmTWUJq0mU4EVnghvkY9OaZRIAPtBwsUOBYpunEx3JfWd2+9kLuVUqT
         vk3nWBB8/n+fVegBOWGSY204dSI3iANk04FsRTo0ihOl3abMV67fnUrAvuZD4rktkho6
         BhArz/2cMsh5ve7pUL31jOJddY7OFoeT1hCsQ=
Message-ID: <bcb7aa500808131837h1590aec5m2082cc3cac835e5a@mail.gmail.com>
Date: Wed, 13 Aug 2008 22:37:17 -0300
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "Rasmus Lerdorf" <rasmus@lerdorf.com>, 
	"Gregory Beaver" <greg@chiaraquartet.net>, 
	"Stanislav Malyshev" <stas@zend.com>, 
	"Marcus Boerger" <helly@php.net>, internals@lists.php.net
In-Reply-To: <D2E02683-76AF-43F9-8EFE-7BDB297F8BA8@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <909776579.20080803142659@marcus-boerger.de>
	 <48A32817.4020105@zend.com>
	 <10910129111.20080813213721@marcus-boerger.de>
	 <48A33D86.1010806@zend.com>
	 <59637275.20080813221213@marcus-boerger.de>
	 <48A34180.8070601@zend.com>
	 <0D64C8C4-2136-4D6B-9EBD-B5956C3044FC@pooteeweet.org>
	 <48A36394.2040408@chiaraquartet.net> <48A36617.5010803@lerdorf.com>
	 <D2E02683-76AF-43F9-8EFE-7BDB297F8BA8@pooteeweet.org>
Subject: Re: [PHP-DEV] Inconsistencies in 5.3
From: guilhermeblanco@gmail.com ("Guilherme Blanco")

I read parts of the thread and I'm curious about a situation that
seems Marcus' patch will deny.
It seems that it'll be denied the possibility to require/include a
file inside of a method of a class/function inside a namespace.

Now I need to bring a situation where maybe Doctrine will implement.
We may have the namespace Doctrine and inside of it a function or
maybe a method called autoload. This one will be linked with
spl_register_autoload.
This method actually includes a file on script and since the autoload
is inside namespace Doctrine and the file included may be part of
namespace Doctrine::XXX::YYY, how will it work?
It seems Marcus' patch denies this possibility.

I review the earlier implementations of namespace support, but now I'm
curious what's the real issue with namespaces and included files.
Please, please please, that's not a flaming discussion. I just want to
have things clear in my head why this design decision was taken.

IMHO, if I have something like:

namespace Doctrine {
  function autoload($class) { include 'Doctrine/Orm/Entity.php'; }
}

And...:

namespace Doctrine::Orm {
  class Entity { ... }
}

The included file should have 2 different possibilities of being processed:
1- It is called in global scope, so it'll be able to Doctrine::Orm::Entity
2- It is called in local scope. This is something that would be
awesome, but would lead compilers crazy. How?
The example:

namespace Doctrine {
    function autoload($class) { include 'Doctrine/Orm/Entity.php'; }
}

And...:

namespace Orm
{
    class Entity { ... }
}

And since include was done inside Doctrine namespace, it'd be
accessible through Doctrine::Orm::Entity.

This would lead after some time into a newer request of users...

namespace Foo {
  namespace Bar {
    class Baz { ... }
  }
}

// Acess as Foo::Bar::Baz

Or even:

namespace Foo::Bar {
  namespace Baz::Wee {
    class Blah { ... }
  }
}

// Acess as Foo::Bar::Baz::Wee:Blah

In this situation, if you separate (using the last example), you could
do a simply:

namespace Foo::Bar {
  include 'Baz/Wee.php';
}

And it should result the same thing as my example.


Please notice I do not want to start a "why not use my syntax". I want
answers what can be accomplish, what cannot be accomplished and why
things are possible/impossible.
Lukas knows more than anyone else that we from Doctrine team are
expecting 5.3 to be a God master in namespace and waiting for a full
scope to be defined (and win release work) to start to port our code.



Thanks in advance,


Cheers,


On Wed, Aug 13, 2008 at 8:00 PM, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>
> On 14.08.2008, at 00:54, Rasmus Lerdorf wrote:
>
>> Gregory Beaver wrote:
>>>
>>> Lukas Kahwe Smith wrote:
>>>>
>>>> On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
>>>>
>>>>> Simply include a script from two locations with different namespaces
>>>>> or one
>>>>>>
>>>>>> with namespace and the otherone without.
>>>>>
>>>>> I'm afraid you misunderstand how namespaces work. As I explained
>>>>> numerous times, namespaces are file-local, and this when including
>>>>> file, it does not matter a bit what was including context.
>>>>
>>>> I think Marcus is talking about files that are included that do not
>>>> specify a namespace explicitly. In this situation the context does
>>>> matter.
>>>>
>>>> We do not know if the developer in question is aware that the context
>>>> would matter in this case. Actually like I said in a previous email it
>>>> would be nice to at least not throw a warning if the file that is
>>>> included specifies an explicit namespace (I assume that is possible?).
>>>> Maybe adding a new "include" is a solution. This way developers can say
>>>> explicitly what they want to do without having to suppress the warning.
>>>> Then again quickly some smartass developer is going to teach people that
>>>> these annoying warnings go away if you just use this new include
>>>> everywhere. Then again, I am not sure if I even have my head wrapped
>>>> around this entire namespace thing.
>>>
>>> Hi,
>>>
>>> Currently, if you include a file within a class method that contains
>>> function definitions, they remain functions outside the class.  If you
>>> include a file that contains a class.
>>>
>>> In short, only global cpde is executed in the scope, and there is no
>>> precedent in PHP to redefine re-usable elements based on scope.
>>>
>>> Why would namespaces be any different?  This whole argument makes no
>>> sense to me.
>>
>> Well, it depends how you view the scope.  If you include a file that
>> defines a variable from within a function or a method, that variable becomes
>> function-scoped, not global.  In the case of a namespaced function or method
>> including a file containing functions or classes, those classes become
>> global.  That has, of course, always been the case, but we haven't had the
>> concept of a namespace context before and we haven't had anything that was
>> file-scoped like this.  So people might extrapolate from the
>> function-context case to this and assume the wrong thing.  That's what
>> Marcus' patch it about.
>>
>> I happen to disagree with him and I think we should just write really good
>> docs explaining how namespaces work and provide a lot of examples.
>
>
> My previous comments were wrong. Sorry about causing confusion. As Rasmus
> points out what Marcus is trying to solve with the warning is the false
> expectation that something that is included in a namespace would also be
> namespaced. This is not the case. As such if you want the included code to
> be in some namespace you have to explicitly do so in the file that is being
> included.
>
> As such I also agree that we do not need a warning. It will do at least as
> much harm to legitimate uses as it tries to solve for illegitimate uses. And
> those problematic users will hopefully decide to read out docs ..
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil