I disagree here...it is both wanted and and needed. This feature has been promised to the community for quite some time now and I'd simply remind you you do have the option of not using namespaces if you don't want too. If you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like it, don't use it but I think working through the remaining issues and getting it out is important. Making right decision on the approach is important too and from an outsiders point of view a lot of progress has been made and it now seems very, very close to being a reality. Ditching it should be the last thing considered.
I can't say it enough, if you don't like where the namespace implementation ends up you can simply decide not to use it.
--Tony
----- Original Message ----
From: Kevin Waterson kevin@phpro.org
To: internals@lists.php.net
Sent: Tuesday, September 23, 2008 3:57:41 PM
Subject: Re: [PHP-DEV] true namespaces, yet another point of view
This one time, at band camp, "jvlad" dmda@yandex.ru wrote:
May I suggest something in this area?
May I suggest something also.. Lets just let namespaces die and let
it become a repressed memory as it seems it is more trouble that it
is worth. Seriously.
For 10+ years we have got on just fine without them, and the amount
of work to get a second-best implementation that nobody agrees on
hardly seems benificial. The gains of namespaces are minimal at best,
because a few cannot be bothered with some simple prefixing.
PHP 5.3 release is looming, and there is STILL conflict about implementation.
The current approach is a long way from what was thought of as namespace
support and it seems nobody is completely happy with any model that
has been put forward. The current implementation is nothing but a series
of comprimses, each one taking away a little of the functionality that
was first envisaged.
Lets just let it die. It is un-needed, un-wanted by many, and the end
result seems to be less that optimal, or even a true implementation
of namespaces.
Kevin
Tony Bibbs wrote:
I disagree here...it is both wanted and and needed. This feature has been promised to the community for quite some time now and I'd simply remind you you do have the option of not using namespaces if you don't want too. If you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like it, don't use it but I think working through the remaining issues and getting it out is important. Making right decision on the approach is important too and from an outsiders point of view a lot of progress has been made and it now seems very, very close to being a reality. Ditching it should be the last thing considered.
I can't say it enough, if you don't like where the namespace implementation ends up you can simply decide not to use it.
--Tony
As far as I know, that argument doesn't really fly here, since you might
not use it, but in a large PHP project, someone in your team will. "If
you don't like it, don't use it" doesn't hold since you still have to
understand, and possibly modify, your teammate's code. A similar point
was raised, IIRC, for the [1,2] short-array notation.
This is particularly important because large codebases, usually with
several people touching the code, are the primary target for namespaces,
as opposed to short one-person form-processing scripts,.
- Federico
Federico Lebron wrote:
Tony Bibbs wrote:
I disagree here...it is both wanted and and needed. This feature has
been promised to the community for quite some time now and I'd simply
remind you you do have the option of not using namespaces if you
don't want too. If you like REALLY_LONG_CLASS_NAMES that's still
perfectly valid. Don't like it, don't use it but I think working
through the remaining issues and getting it out is important. Making
right decision on the approach is important too and from an outsiders
point of view a lot of progress has been made and it now seems very,
very close to being a reality. Ditching it should be the last thing
considered.
I can't say it enough, if you don't like where the namespace
implementation ends up you can simply decide not to use it.--Tony
As far as I know, that argument doesn't really fly here, since you might
not use it, but in a large PHP project, someone in your team will. "If
you don't like it, don't use it" doesn't hold since you still have to
understand, and possibly modify, your teammate's code. A similar point
was raised, IIRC, for the [1,2] short-array notation.
This is particularly important because large codebases, usually with
several people touching the code, are the primary target for namespaces,
as opposed to short one-person form-processing scripts,.
In addition one of the main reasons FOR namespace is to make libraries easier
to manage, so if our own code does not use them it's likely that some library
we select will - at some point. Hence my comments previously about having to
take more care keeping things like namespace under control when deploying
applications which may not have 5.3 available to run on. BC up to now has been
relatively easy to maintain, but I have a feeling that 5.3 SHOULD be a major
version number change so that we can maintain PHP5 compatibility easier?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
I share your thoughts and yes namespaces are needed and wanted, but what's
implemented at the moment is quite far from what I'd call a namespace. I
need and want to see there all language entities including variables,
constants, classes, interfaces, and functions. Want to see them all
supported by namespaces or nothing.
-JV
I disagree here...it is both wanted and and needed. This feature has been
promised to the community for quite some time now and I'd simply remind you
you do have the option of not using namespaces if you don't want too. If
you like REALLY_LONG_CLASS_NAMES that's still perfectly valid. Don't like
it, don't use it but I think working through the remaining issues and
getting it out is important. Making right decision on the approach is
important too and from an outsiders point of view a lot of progress has
been made and it now seems very, very close to being a reality. Ditching
it should be the last thing considered.I can't say it enough, if you don't like where the namespace
implementation ends up you can simply decide not to use it.--Tony