Hello Andi,
Wednesday, March 26, 2008, 7:12:18 AM, you wrote:
> In general I'd prefer one namespace per-file, at least as a best
> practice and common advertised use. For this case it doesn't really
> matter too much whether it's with or without brackets. My preference is
> without because then you just stick it at the top and don't have an
> extra level of indentation which you'd typically have with brackets.
Since when do we enforce indentation anywher? And once again code I see all
around typically has no indentation for namespaces. What people sometimes
do is to indent if the have smaller stuff they explicitly import. But that
is a C++ specific thing.
> For the not recommended case where you want to combine multiple files
> with a tool I still prefer without brackets. The brackets again add
> indentation and in addition, it's not really clear whether you can put
> code in between namespaces definitions (between closing "}" and
> "namespaces" keyword). You shouldn't be able to and without brackets
> that becomes much more clear because current namespace is relevant until
> the next namespace declaration; thus never allowing a "gap".
> I think it's important for people to consider the former reasons as I
> think without {} will lead be more intuitive and will lead to less
> indentation.
Thanks for explaining your thoughts.
But I must be missing something completely here. Were do the indents come
from? And also I think quite the opposite is intuitive. Braces for
namespaces give you some control of where a namespace starts and where it
ends.
Last part is regarding the ability of multiple namespaces and no code
befaore, after or in between namespaces. Now first thing to recognize is
that having no braces for namespaces solves the issue of before, between
and after namespaces as there no longer is a between or after. But now it
is extremely unclear whether a namespace after a namespace is nesting or a
new namespace. Hence completely unintuitive. Especially since there is no
language out there that is in use and has anything like that. And even more
scary to me, you did not solve anything by this because people still could
write code prior to the namespace keyword. So no matter what we are screwed
and create a new version php scripts. Which I consider pretty bad. So
should we reconsider the limitation and have an anonymous namespace that
this code goes to? If not, how do we enforce this rule? How do we explain
that to users?
marcus
>> -----Original Message-----
>> From: Gregory Beaver [mailto:[EMAIL PROTECTED]
>> Sent: Friday, March 21, 2008 3:01 PM
>> To: Marcus Boerger
>> Cc: internals@lists.php.net
>> Subject: [PHP-DEV] Re: [RFC] Namespace syntax decision
>>
>> Marcus Boerger wrote:
>> > Hello Internals,
>> >
>> > we all were asked to stop discussing syntax of namespaces as we
>> were told
>> > that we would decide after the namespace functionality was fully
>> implemented.
>> > Now I think that the functionallity is pretty much settled we should
>> > revisit the syntax. We all have been very patient so far. Anyway
> here
>> goes
>> > my take on it:
>> >
>> > PHP is very close to Java and C++ in terms of Syntax. And many of
> our
>> users
>> > are familiar with one or even both of them. Also we have a tendency
>> to
>> > especially take syntax from those two or be in line with those two
>> > languages. That said I see two ways:
>> >
>> > 1) namespace foo { }
>>
>> This is acceptable if nothing can exist outside namespace foo {}
> except
>> declare and other namespace declarations.
>>
>> >
>> > 2) package foo;
>> >
>> > I favor 1) if we allow namespace nesting and 2) if not. The current
>> way of
>> > nesting is very confusing:
>> > namespace foo; namespace bar;
>>
>> I prefer this syntax because it discourages multiple namespaces, but
>> still allows them (nesting is an inaccurate term in this case, I
>> strongly encourage not using it)
>>
>> Greg
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
