Re: [PHP-DEV] Suggestion: Namespace implementation
On Thursday 27 December 2007, Hans Moog wrote: In my oppinion namespaces should only be an additional way of structering php elements and using short names again without loosing the abilitiy to avoid naming conflicts with 3rd party libraries. Since libraries are generally class libraries and because of already being able to group variables, constants and functions in static classes i see no reason for namespaces to affect the resolution of the previously mentioned elements. Instead, they should only affect classes enabling the coder to tie packages and use or provide libraries. Libraries are generally class libraries is both wrong and very limiting. There is nothing wrong with functions. Thousands of professional web sites run on systems that have not a single class in them quite successfully. There are plenty of situations where going all OO is not a good thing, and results in more code complexity, not less. A complete namespace implementation supports both classes and functions equally. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Suggestion: Namespace implementation
Within the last few days i read some of the posts concerning the new
namespace implementation and it's alleged problems. And ... I really
have to say, that I do not understand whats the problem with namespaces
at all. Instead, I suppose that many lost sight of the original goal of
namespaces.
In my oppinion namespaces should only be an additional way of
structering php elements and using short names again without loosing the
abilitiy to avoid naming conflicts with 3rd party libraries. Since
libraries are generally class libraries and because of already being
able to group variables, constants and functions in static classes i see
no reason for namespaces to affect the resolution of the previously
mentioned elements. Instead, they should only affect classes enabling
the coder to tie packages and use or provide libraries.
By the way ... why should it be possible to write something like this:
?php
namespace Array;
define('CALL_MODIFIER1', 1);
function merge() {
/* ... code ... */
}
?
to express Array::merge().
If we are already able to express the same thing by writing something
like this:
?php
class Array {
const CALL_MODIFIER = 1;
public static function merge() {
}
}
?
even leaving us the opportunity to later group the static classes into
an additional package by additionally defining a namespace in the file.
If we decide to limit namespaces to classes, we are able to define some
very easy rules that are able to be applied during compile time without
having any runtime evaluation, making namespaces really fast:
If there is a namespace declaration in the current file {
1. all classes defined in this file are prefixed with the namespace.
2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are prefixed with the defined namespace.
3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.
4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)
} else {
1. all classes defined in this file are not prefixed with a namespace
2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are NOT prefixed.
3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.
4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)
}
Example with a namespace declaration:
?php
namespace framework::email;
use framework::database; // import other package
use ArrayAccess; // import global class
class MailServer implements ArrayAccess {
public function connect() {
$database = database::DBFactory::getInstance();
$protocol = new Pop3Protocol();
if(...) {
throw new Exception('message', 0);
} else {
throw new ::Exception('message', 0);
}
}
}
class Exception extends ::Exception {
}
?
will be compiled to:
?php
class framework::email::MailServer implements ArrayAccess {
public function connect() {
$database = framework::database::DBFactory::getInstance();
$protocol = new framework::email::Pop3Protocol();
if(...) {
throw new framework::email::Exception('message', 0);
} else {
throw new Exception('message', 0);
}
}
}
class framework::email::Exception extends Exception {
}
?
Example without a namespace declaration:
?php
use framework::database; // import other package
use ArrayAccess; // import global class (useless)
class MailServer implements ArrayAccess {
public function connect() {
$database = database::DBFactory::getInstance();
$protocol = new Pop3Protocol();
if(...) {
throw new Exception('message', 0);
} else {
throw new ::Exception('message', 0);
}
}
}
class MailException extends ::Exception {
}
?
will be compiled to:
?php
class MailServer implements ArrayAccess {
public function connect() {
$database = framework::database::DBFactory::getInstance();
$protocol = new Pop3Protocol();
if(...) {
throw new Exception('message', 0);
} else {
throw new Exception('message', 0);
}
}
}
class MailException extends Exception {
}
?
So ... we would be able have short names without being scared of naming
conflicts with core functions or breaking backward compatibility. And we
would still be able to express the same things as if we would allow
namespace for functions, variables and constants by declaring them in
static classes.
PS: Just a suggestion so don't kill me :o)
[PHP-DEV] Suggestion: Namespace implementation
Within the last few days i read some of the posts concerning the new
namespace implementation and it's alleged problems. And ... I really
have to say, that I do not understand whats the problem with namespaces
at all. Instead, I suppose that many lost sight of the original goal of
namespaces.
In my oppinion namespaces should only be an additional way of
structering php elements and using short names again without loosing the
abilitiy to avoid naming conflicts with 3rd party libraries. Since
libraries are generally class libraries and because of already being
able to group variables, constants and functions in static classes i see
no reason for namespaces to affect the resolution of the previously
mentioned elements. Instead, they should only affect classes enabling
the coder to tie packages and use or provide libraries.
By the way ... why should it be possible to write something like this:
?php
namespace Array;
define('CALL_MODIFIER1', 1);
function merge() {
/* ... code ... */
}
?
to express Array::merge().
If we are already able to express the same thing by writing something
like this:
?php
class Array {
const CALL_MODIFIER = 1;
public static function merge() {
}
}
?
even leaving us the opportunity to later group the static classes into
an additional package by additionally defining a namespace in the file.
If we decide to limit namespaces to classes, we are able to define some
very easy rules that are able to be applied during compile time without
having any runtime evaluation, making namespaces really fast:
If there is a namespace declaration in the current file {
1. all classes defined in this file are prefixed with the namespace.
2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are prefixed with the defined namespace.
3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.
4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)
} else {
1. all classes defined in this file are not prefixed with a namespace
2. all classes without an additional namespace prefix (meaning
everything with X::method|variable|constant) which were not imported
are NOT prefixed.
3. all classes with a name that was imported get resolved by replacing
the imported alias with the imported path.
4. all other classes (especially Y::X::method|variable|constant)
that were not imported are resolved as beeing full paths (remaining
unmodified)
}
Example with a namespace declaration:
?php
namespace framework::email;
use framework::database; // import other package
use ArrayAccess; // import global class
class MailServer implements ArrayAccess {
public function connect() {
$database = database::DBFactory::getInstance();
$protocol = new Pop3Protocol();
if(...) {
throw new Exception('message', 0);
} else {
throw new ::Exception('message', 0);
}
}
}
class Exception extends ::Exception {
}
?
will be compiled to:
?php
class framework::email::MailServer implements ArrayAccess {
public function connect() {
$database = framework::database::DBFactory::getInstance();
$protocol = new framework::email::Pop3Protocol();
if(...) {
throw new framework::email::Exception('message', 0);
} else {
throw new Exception('message', 0);
}
}
}
class framework::email::Exception extends Exception {
}
?
Example without a namespace declaration:
?php
use framework::database; // import other package
use ArrayAccess; // import global class (useless)
class MailServer implements ArrayAccess {
public function connect() {
$database = database::DBFactory::getInstance();
$protocol = new Pop3Protocol();
if(...) {
throw new Exception('message', 0);
} else {
throw new ::Exception('message', 0);
}
}
}
class MailException extends ::Exception {
}
?
will be compiled to:
?php
class MailServer implements ArrayAccess {
public function connect() {
$database = framework::database::DBFactory::getInstance();
$protocol = new Pop3Protocol();
if(...) {
throw new Exception('message', 0);
} else {
throw new Exception('message', 0);
}
}
}
class MailException extends Exception {
}
?
So ... we would be able have short names without being scared of naming
conflicts with core functions or breaking backward compatibility. And we
would still be able to express the same things as if we would allow
namespace for functions, variables and constants by declaring them in
static classes.
PS: Just a suggestion so don't kill me :o)
