I've been reading this lengthy discussion and here's a sumup of what I
found:
- PHP's implementation is only a part of what most people expect to find
when they hear "php has namespace support"
- PHP's implementation looks a bit like JAVA's package support, and a
bit like many other (differently names) features in other languages. It
however does not match 1:1 to any of those.
So, everyone here has agreed already that "namespaces" !=== PHP's
implementation (it might ==, but not ===). Same goes for Package.
I find the idea of Greg to be very good though, reading the original
proposal, it often names things not "namespace" but simply "prefix".
What do you do with your names? you use a prefix, you don't expect it to
have "full namespace support just like [insert any other language
here]", nor do you expect it to "be exactly like a JAVA package".
When announced, you could simply state "PHP now has support for
prefixing, PHP's own specific implementation of namespaces". Because
that's what you have, you can complain that "according to the definition
of [word] it _is_ that.", but you can't really. The "definition" of a
word like namespace, package, etc. is not independent of its
implementation in majorly used languages unfortunately. If you ask a
random coder "what is a namespace", the answer will always be based on
an implementation in a language the person uses/likes a lot. You can
quote from wikipedia, but that doesn't really mean anything (sorry
Stas), what we should try to do here is find the proper name which
identifies the implementation we have for what it is.
prefix Foo;
alias Foo:Bar as Quux;
Looks very good to me as it clearly shows what happens, internally and
externally. It's not a namespace as such, it's not a package as such,
it's simply what PHP _does_.
I hope this will help the discussion steer away from the standard
arguments that have been used constantly, and that will simply not change.
- Tul
Gregory Beaver wrote:
Hi,
All of the debate over whether this is a true namespace implementation
is in my opinion completely bogus (translate: I think "namespace" is a
fine choice for the reserved word, and "package" is a dangerously
misleading choice), but since there is so much noisy dissent, I have an
alternative proposal I'd like to float:
How about using the keyword "prefix" or "nameprefix" instead of
"namespace"? This will be clearer and can be easily defined with 2
sentences similar to the original proposal: "All class and function
names inside the file are automatically prefixed with the
(prefix|nameprefix) name. In other files, classes and functions can be
imported with different names (aliases) to eliminate naming conflicts or
reduce typing needed."
I quote from the original "Simple Namespace Proposal" message by Dmitry:
From the beginning:
Main assumption of the model is that the problem that we are to solve is the
problem of the very long class names in PHP libraries. We would not attempt
to take autoloader's job or create packaging model - only make names
manageable.
From the middle:
Namespace definition does the following:
All class and function names inside are automatically prefixed with
namespace name.
As stated, because this proposal *only* defines a prefix for functions
and class names, it is not a packaging model. All package models in
existence define some kind of self-contained entity that groups related
*files* and their contents together in a way that allows them to be
"packaged" into a single thing, like a jar, a PEAR .tgz, or a .phar
file. This proposal does none of these things. Simply because the
prefix is defined per-file does not a package make. By the same logic,
using ".php" at the end of a file or ".dat" at the end of a file creates
special packages of php or dat information, because the extension
applies to the whole file at once. Simply defining the contents of a
file does not imply any organization whatsoever.
What the original proposal *does* do is provide a namespace prefix - it
defines a scope within which all names have a special prefix. This is
not rocket science.
<rant>On a personal note, if you feel you must reply to this thread
further, please follow this checklist:
1) is anything I am saying bring a new idea to the debate?
2) is there a patch that converts my new idea into a reality attached to
the message?
If you can't answer "yes" to either of these, please go immediately to
jail, do not pass go, do not collect $200.</rant>
Thank you to Dmitry for this much-needed idea.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
