What if you want to provide a set of helper/wrapper classes, appropriately
namespaced, something along the lines of:
MyFramework\Helpers\Array
MyFramework\Helpers\Database
MyFramework\Helpers\Session
etc.
If I want to use that naming convention, I don't want to have to name some
of my classes differently just because PHP can't deal with it. It may not be
trivial to fix, but to the end-developer, it's a trivial problem and it's
something that should just work.
Dan
On Thu, Nov 6, 2008 at 3:54 AM, Larry Garfield <[EMAIL PROTECTED]>wrote:
> On Wednesday 05 November 2008 9:24:15 pm Stan Vassilev | FM wrote:
> > Hi,
> >
> > I just wanted a clarification on this. Currently many of us have class
> > names such as:
> >
> > Zend_Validate_Interface
> > Foo_Utils_Array
> >
> > ...and so on. This works fine as it's just a single T_STRING.
> >
> > As you know, with the new convention, the parser will not encounter
> > T_STRING "Zend\Validate\Interface" but rather:
> >
> > T_STRING "Zend"
> > T_NS_SEPARATOR "\"
> > T_STRING "Validate"
> > T_NS_SEPARATOR "\"
> > T_INTERFACE <-- parse error
> >
> > I understand it's not trivial to fix this, but I wanted a clarification:
> is
> > there a plan to do something about it, or it'll remain an invalid syntax
> by
> > the time of release of 5.3.
> >
> > Regards,
> > Stan Vassilev
>
> Since I don't see why anyone would want to map the name that directly in
> the
> first place, I don't see anything here to fix. In that example, if you
> imported Zend\Validate\Interface you would then have to use it as:
>
> class Bob implements Interface { }
>
> Which is of course wrong on many levels. I'd file this under "if it breaks
> when you do that, don't do that". :-)
>
> --
> Larry Garfield
> [EMAIL PROTECTED]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
