Re: Re: towards a 5.3 release
| From: | Robert Cummings | Date: | Mon, 08 Sep 2008 18:52:25 +0000 |
| Subject: | Re: Re: towards a 5.3 release | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-40368@lists.php.net to get a copy of this message | ||
On Mon, 2008-09-08 at 14:45 -0400, Robert Cummings wrote:
> On Mon, 2008-09-08 at 14:39 -0400, Elizabeth M Smith wrote:
> > Stanislav Malyshev wrote:
> > > Hi!
> > >
> > >> And what happens when you have two libraries and each has their own Date
> > >> implementation? How is that any different? If you could alias in
> > >> functions, you'd simply alias them in differently - call one _() and one
> > >> new_gettext - that's the point of aliasing, to avoid collisions
> > >
> > > It's not different. But if you can have _() and new_gettext() - how
> > > exactly is it so much better than Foo::_() and Bar::_()? So different
> > > that the former is OK but the latter is absolutely useless? Just because
> > > it the latter has ::?
> >
> > What is the point? Wouldn't it be just as well to have static methods
> > in a class instead? What do I gain by having functions in namespaces?
> > For me it's useless because there's another way to do exactly the same
> > thing...don't we already have enough of that in PHP?
>
> Bad argument... there's another way to do namespaces without namespaces
> too... it's called prefixing. Many, many, MANY developers still take a
> procedural approach to development and as such many functions have the
> naming conflicts. These libraries (as they may be) are not necessarily
> under the control of the person wanting to use them and so punting
> functions to classes may not be a viable option.
In case it wasn't obvious btw, I was advocating namespace support for
functions and not suggesting prefixing :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP