Hello Guilherme,
Thursday, August 14, 2008, 3:37:17 AM, you wrote:
> 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 <[EMAIL PROTECTED]> 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 ..
Autoload is different and I am still collecting opinions here to see what
needs to be done. One solution might be to invoke the autoload chain always
from the global namespace. Maybe only do the namespace reset from within
SPLs autoload. This is by the way independend from the discussion whether
we should issue warnings when include/require occurs inside a namespaced
function/method.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
