Hi, Has anyone thought of the keyword "phpspace"? 2007/8/17, M. Sokolewicz <[EMAIL PROTECTED]>: > > 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 > >
-- Best regards, Jingcheng Zhang Room 304, Dormitory 26 of Yuquan Campus, Zhejiang University P.R.China
