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 ..
>
> regards,
> Lukas Kahwe Smith
> [EMAIL PROTECTED]
>
>
>
>
> --
> 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: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
