Forgive me if I've missed this in the heat of all the namespaces discussions. Did we
consider having reserved namespaces, like 'PHP' or 'SPL', so that if a user tries to
declare a namespace with that name an error is raised?
-Andrei
Forgive me if I've missed this in the heat of all the namespaces
discussions. Did we consider having reserved namespaces, like 'PHP' or
'SPL', so that if a user tries to declare a namespace with that name an
error is raised?
I'd say what you are looking for is probably this.
http://wiki.php.net/rfc/namespaces-for-internal-classes
I know this has been discussed but I'm not sure if any decision has
been made on that subject. Or if anyone had time to start digging into
this issue further than discussions. Lars?
Cheers,
--
Slan,
David
Forgive me if I've missed this in the heat of all the namespaces
discussions. Did we consider having reserved namespaces, like 'PHP' or
'SPL', so that if a user tries to declare a namespace with that name an
error is raised?
I don't think we have to treat our users like a total fcking idiots.
If anyone thinks using "SPL" or "PHP" as their root namespace is a
good idea they deserve to be kicked in the nuts.
-Hannes
Hannes Magnusson wrote:
I don't think we have to treat our users like a total fcking idiots.
If anyone thinks using "SPL" or "PHP" as their root namespace is a
good idea they deserve to be kicked in the nuts.
And who's going to administer this kicking?
-Andrei
Hannes Magnusson wrote:
I don't think we have to treat our users like a total fcking idiots.
If anyone thinks using "SPL" or "PHP" as their root namespace is a
good idea they deserve to be kicked in the nuts.And who's going to administer this kicking?
I think the decision was to not yet bother with reserving namespaces
or starting to namespace-ify extensions. We might however want to put
out a naming guide for namespaces.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
I think the decision was to not yet bother with reserving namespaces or
starting to namespace-ify extensions. We might however want to put out a
naming guide for namespaces.
I agree. Whether the error is raised or not on reserved namespaces can be done later, but
we should explicitly indicate that certain namespaces are off-limits.
-Andrei
Lukas Kahwe Smith wrote:
I think the decision was to not yet bother with reserving namespaces or
starting to namespace-ify extensions. We might however want to put out a
naming guide for namespaces.I agree. Whether the error is raised or not on reserved namespaces can be
done later, but we should explicitly indicate that certain namespaces are
off-limits.
Could take the simple convention that exists in perl with modules.
Module names begin with a capital letter, pragmase are lower case, thus you have:
use strict;
use IO::File
Nobody is made to do anything, however you loose the option to complain if your
namespace starts with a lower case character.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
IMHO, the prefix will turn everything more readable...
I already saw people experiencing some doubts regarding this piece of
code. I had to illustrate it everything.
namespace Foo;
class Bar
{
public function test()
{
try {
do_some_stuf();
} catch (Exception $e) { // Refers to Foo\Exception
// Special handling of Foo Exception
} catch (\Exception $e) { // Refers to PHP Exception
// Special handling of Exception
}
}
}
I just updated the code to explain wtf is happening... but he was just
trying to do a simple try { .. } catch (Exception $e) { ... } and
thought it was a bug since it was refering to Foo\Exception. Sounds
newbie, but you will have troubles in the future.
Regards,
Lukas Kahwe Smith wrote:
I think the decision was to not yet bother with reserving namespaces or
starting to namespace-ify extensions. We might however want to put out a
naming guide for namespaces.I agree. Whether the error is raised or not on reserved namespaces can be
done later, but we should explicitly indicate that certain namespaces are
off-limits.Could take the simple convention that exists in perl with modules.
Module names begin with a capital letter, pragmase are lower case, thus you have:
use strict; use IO::FileNobody is made to do anything, however you loose the option to complain if your
namespace starts with a lower case character.--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h>--
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
Lukas Kahwe Smith wrote:
Hannes Magnusson wrote:
I don't think we have to treat our users like a total fcking idiots.
If anyone thinks using "SPL" or "PHP" as their root namespace is a
good idea they deserve to be kicked in the nuts.And who's going to administer this kicking?
I think the decision was to not yet bother with reserving namespaces or
starting to namespace-ify extensions. We might however want to put out a
naming guide for namespaces.
Things gettings reserved at a later stage (like originally keywords, now
namespaces) can lead to a big deal of frustration. Therefore I think it
is crucial to have a clear naming guide now.
And these guidelines have to be noticed by everybody who starts to use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they can't be
missed.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are reserved
but never used.
My two cents,
- Chris
Things gettings reserved at a later stage (like originally keywords, now
namespaces) can lead to a big deal of frustration. Therefore I think it
is crucial to have a clear naming guide now.
+1
And these guidelines have to be noticed by everybody who starts to use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they can't be
missed.
No:
- there are occasional times when rules might want to be broken
- to enforce it just makes the language/compiler bigger
- If it is advertised and someone breaks the rules - then it is their problem.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are reserved
but never used.
As I suggested, do it the way that perl does: it is keyed off the case of the characters.
So, the reserved spaces could be one of:
- entirely lower case (or perhaps just start with lower case)
- entirely upper case
- start with an underscore ('_')
Perl does (1).
It might be better to do (2) because system variables tend to be in upper case
anyway (think: $_GET). (3) also has the virtue that system things tend to start
with an underscore.
This scheme is nice and simple.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Alain Williams wrote:
Things gettings reserved at a later stage (like originally keywords, now
namespaces) can lead to a big deal of frustration. Therefore I think it
is crucial to have a clear naming guide now.+1
And these guidelines have to be noticed by everybody who starts to use
namespaces so they have to be placed prominently.Personally I'd even prefer them to be enforced in code so they can't be
missed.No:
- there are occasional times when rules might want to be broken
- to enforce it just makes the language/compiler bigger
- If it is advertised and someone breaks the rules - then it is their problem.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are reserved
but never used.As I suggested, do it the way that perl does: it is keyed off the case of the characters.
So, the reserved spaces could be one of:
- entirely lower case (or perhaps just start with lower case)
- entirely upper case
People, can we all agree to remember that PHP is case-insensitive with
the exception of variable names and a few constants?
Thanks,
Greg
Christian Schneider wrote:
Things gettings reserved at a later stage (like originally keywords, now
namespaces) can lead to a big deal of frustration. Therefore I think it
is crucial to have a clear naming guide now.And these guidelines have to be noticed by everybody who starts to use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they can't be
missed.Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are reserved
but never used.
Just a gentle reminder to make sure we don't miss this..
-Andrei
Christian Schneider wrote:
Things gettings reserved at a later stage (like originally
keywords, now
namespaces) can lead to a big deal of frustration. Therefore I
think it
is crucial to have a clear naming guide now.
And these guidelines have to be noticed by everybody who starts to
use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they
can't be
missed.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are
reserved
but never used.Just a gentle reminder to make sure we don't miss this..
Well cant we just use the class naming guide? As in put a prefix in
your namespace names, do not use an extension name (or something that
could likely become an extension name) as your prefix.
Then again for classes we say that the prefix should be prepended with
an underscore as the separator as the ultimate protection. That of
course does not seem feasible for namespaces.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Christian Schneider wrote:
Things gettings reserved at a later stage (like originally keywords, now
namespaces) can lead to a big deal of frustration. Therefore I think it
is crucial to have a clear naming guide now.
And these guidelines have to be noticed by everybody who starts to use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they can't be
missed.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are reserved
but never used.Just a gentle reminder to make sure we don't miss this..
Well cant we just use the class naming guide? As in put a prefix in your
namespace names, do not use an extension name (or something that could
likely become an extension name) as your prefix.Then again for classes we say that the prefix should be prepended with
an underscore as the separator as the ultimate protection. That of
course does not seem feasible for namespaces.
-1 for using existing guide
Please don't make us do this
<?php
namespace God_No/Required/Underscores/Please;
?>
This is fine:
<?php
namespace ThisHere/Is/Fine;
?>
Greg
Christian Schneider wrote:
Things gettings reserved at a later stage (like originally
keywords, now
namespaces) can lead to a big deal of frustration. Therefore I
think it
is crucial to have a clear naming guide now.
And these guidelines have to be noticed by everybody who starts to
use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they
can't be
missed.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are
reserved
but never used.Just a gentle reminder to make sure we don't miss this..
So where are we at here?
If nobody proposes something, this will just slide by ..
I guess we can say that there is a definate risk, that eventually
extensions will become namespaced. Same for internal functions.
So calling a namespace "Date" or "str" is probably not a good idea ..
right?
Now for the less obvious stuff .. does the ZF prefix all their top
level namespaces with ZF etc.?
Speaking of ZF ... wasnt there an effort over at ZF to define a
sensible standard?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
If nobody proposes something, this will just slide by ..
It seems simple enough to add a note on the manual page reserving the
use of some namespaces:
PHP (even if we never use it, best no-one else does)
internals (ditto)
SPL (reserved for SPL)
PEAR (reserved for PEAR)
PECL (reserved for PECL)
Though we could add a simple check to the parser, I see no real need
if we make this list conspicuous enough. Once the users have been
warned, we are in a better position to administer their kick to the
nuts.
Paul
--
Paul Biggar
paul.biggar@gmail.com
IMHO any extension name should be reserved as a namespace.
Ilia Alshanetsky
On Tue, Mar 31, 2009 at 12:28 AM, Lukas Kahwe Smith <mls@pooteeweet.org
wrote:
If nobody proposes something, this will just slide by ..It seems simple enough to add a note on the manual page reserving the
use of some namespaces:PHP (even if we never use it, best no-one else does)
internals (ditto)
SPL (reserved for SPL)
PEAR (reserved for PEAR)
PECL (reserved for PECL)Though we could add a simple check to the parser, I see no real need
if we make this list conspicuous enough. Once the users have been
warned, we are in a better position to administer their kick to the
nuts.Paul
--
Paul Biggar
paul.biggar@gmail.com
Lukas Kahwe Smith wrote:
Christian Schneider wrote:
Things gettings reserved at a later stage (like originally keywords, now
namespaces) can lead to a big deal of frustration. Therefore I think it
is crucial to have a clear naming guide now.
And these guidelines have to be noticed by everybody who starts to use
namespaces so they have to be placed prominently.
Personally I'd even prefer them to be enforced in code so they can't be
missed.
Removing restrictions later on causes less trouble so I wouldn't mind
too much if a couple of namespaces (or namespace prefixes) are reserved
but never used.Just a gentle reminder to make sure we don't miss this..
So where are we at here?
If nobody proposes something, this will just slide by ..
I propose reserving PHP. extensions can be PHP\extname (i.e. class
PHP\Phar, or for extensions with multiple levels of hierarchy
PHP\PDO\mysql etc.)
Alternately, we forbid namespaces in extensions, and thus users can
guarantee no conflict with PHP internals simply by using them.
Anything else will lead to insanity very quickly. Either we'll get
wonderful conflicts or no way to figure out in advance what namespaces
are OK.
Ilia's suggestion of reserving any extension, current or future, as a
namespace makes it impossible to predict what namespaces should not be
used in userspace, and as we know, extensions can have literally any
name. This, in my opinion, is no option at all, as we need to be able
to know whether names we choose can be safely used with future versions
of PHP.
Greg
Lukas Kahwe Smith wrote:
So where are we at here?
If nobody proposes something, this will just slide by ..I propose reserving PHP. extensions can be PHP\extname (i.e. class
PHP\Phar, or for extensions with multiple levels of hierarchy
PHP\PDO\mysql etc.)
+1
I don't think we should magically raise errors if someone tries to
declare such namespace, but updating the userland naming guide would
be good.
That being said; Would it be possible to enforce the PHP\ internally?
Otherwise extension authors will simply ignore the rule and come up
with their own conventions...
-Hannes
On Tue, Mar 31, 2009 at 04:47, Greg Beaver greg@chiaraquartet.net
wrote:Lukas Kahwe Smith wrote:
So where are we at here?
If nobody proposes something, this will just slide by ..I propose reserving PHP. extensions can be PHP\extname (i.e. class
PHP\Phar, or for extensions with multiple levels of hierarchy
PHP\PDO\mysql etc.)+1
I don't think we should magically raise errors if someone tries to
declare such namespace, but updating the userland naming guide would
be good.
That being said; Would it be possible to enforce the PHP\ internally?
Otherwise extension authors will simply ignore the rule and come up
with their own conventions...
Ok, is this settled now?
Anyone working a patch?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org