Jessie Hernandez wrote:
Hi Greg,
I've read through the posts and the RFC and am not sure if this was
discussed before, but there is one other proposal I'd like to throw out
there: why not require all classes that are inside namespaces to be
explicitly imported? This would follow the AS3 appr
Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove
I'm just a mere user, but if we go for other namespace separator (be it
::: or :> or anything else), then I'd rather see it used both between
namespace and class/function/constant name *and* between namespace parts.
OK, so maybe I should explain one little thing about the significance of
those
Paweł Stradomski wrote:
W liście Ryan Panning z dnia piątek 17 października 2008:
Request Autoload Gets Type
---
A::B:>C A::B:>C Class
A::B:>func() A::BNamespace
A::B:>C::CONST A::B:>C
W liście Ryan Panning z dnia piątek 17 października 2008:
> Request Autoload Gets Type
> ---
> A::B:>C A::B:>C Class
> A::B:>func() A::B Namespace
> A::B:>C::CONST A::B:>C Class
> A::B::
+1 #3
On Fri, Oct 17, 2008 at 9:35 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
> Greg Beaver wrote:
>
>> Hi,
>>
>> http://wiki.php.net/rfc/namespaceissues
>>
>> Read it and discuss. Let's be clear people: the technical problems in
>> namespaces are limited and solvable. The problems in the poli
Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove
Edmund Tam wrote:
(one::step)::two();
Yes, parenthesis, just like when we want to write (1 + 2) * 3.
So my question is: can parenthesis play a part in namespace resolving?
see this is the problem and where the solution should be (imo)
mynamespace::anotherspace::somespace
Hello all,
Sorry to post here being an "outsider".
I didn't post because I know nothing about the internals, really.
However after some incomplete thought I have a not very thorough
suggestion about the ambiguity issue mentioned in the RFC wiki.
I would like to ask if this is possible.
Let me quo
Hi!
+1 and of course make the resolution as greg mentioned on the rfc in the
resolving access part (actually that was in stas's original original
post and I didn't realize we were still arguing over it ;)
NO, it wasn't in my proposal - my proposal was entirely different. My
proposal does not
On 10/15/08 4:35 PM, Greg Beaver wrote:
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass r
+1 for option 3 too (http://wiki.php.net/rfc/namespaceissues)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Greg, everyone.
Greg Beaver wrote:
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass re
Greg Beaver wrote:
> Hi,
>
> http://wiki.php.net/rfc/namespaceissues
>
> Read it and discuss. Let's be clear people: the technical problems in
> namespaces are limited and solvable. The problems in the political
> environment surrounding them may not be. Wouldn't politics be a
> stupid-ass rea
Hi,
I have no karma but I read almost all threads about namespaces and I
think I understand the issues.
* Conflict between namespaced functions and static class methods:
I prefer #1 but #3 is also good.
* Resolving access to internal classes:
+1 for the solution.
Please don't remove namespac
15 matches
Mail list logo
