2008/9/23 Karsten Dambekalns <[EMAIL PROTECTED]>:
> Hi.
>
> For what it's worth, my point of view:
>
> Stanislav Malyshev wrote:
>>
>> 1. Allow braces for namespaces. So, the syntax for namespaces will be:
>> a) namespace foo;
>> should be first (non-comment) statement in the file, namespace extends to
>> the end of the file or next namespace declaration.
>> b) namespace foo {}
>> can appear anywhere on the top scope (can not be nested).
>
> Full support for the braces, but please *do*not* allow both ways. Why?
> Perl's "more than one way to do it"? If there's one way, it's clear what to
> use. I see absolutely no point in this. Really. Please don't.+1, I would however stick with the braces syntax though, why? Because namespaces aren't really anything than something wrapping around a class in my eyes and I don't see why it needs special treatment, if it has to be one per file, then why not classes aswell, this is like PHP is telling how to design my interface, rather than if I want to have a namespace declaring in a file for some reason or if I wanna have all code mixed in one, then I think I should be allowed to do so, and not having to make multiple files, not that its that big an issue but its still a big -1 with a "ns"-only file. (Please exuse if I have missed something, I tried to keep up with the NS threads, but all these new ones has been alittle to much to overcome). > >> 2. Simplify resolution order for classes in the namespace: unqualified >> names are resolved this way: >> a) check "use" list if the name was defined at "use", follow that >> resolution >> b) if not, the name resolves to namespace::name >> Consequence of this will be that for using internal class inside namespace >> one would need to refer to it either as ::Foo or do use ::Foo prior to its >> usage. > > Fine with me. I'd use ::Foo for internal classes anyway to avoid speed and > ambiguity issues. > >> 3. Functions will not be allowed inside namespaces. We arrived to >> conclusion that they are much more trouble than they're worth, and summarily >> we would be better off without them. Most of the functionality could be >> easily achieved using static class methods, and the rest may be emulated >> with variable function names, etc. > > We roll everything in classes anyway, so fine with me. > > > Regards, > Karsten > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > But overall +1 from me aswell -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
