[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)
AW: AW: [PHP-DEV] Method overloading by method signature
It allows you to be strict when messing with types but it doesn't allow you to overload type hinted methods ... so this is no solution to the problem of overloading type hinted methods, is it ? -Ursprüngliche Nachricht- Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Gesendet: Mo 15.10.2007 18:38 An: Umberto Salsi Cc: internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature That's why I developed PHPLint, a PHP parser and validator that performs a static analysis of the source, ensuring the safe handling of types. In a word, this tool makes PHP very close to a strong-typed language without the need to further complicate the interpreter with new features that would pervert the nature of the language. I think this is better solution than messing with the language :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Method overloading by method signature
And if you have more than one parameter you will name it
methodFromStringIntegerSampleClassBoolean ?!?
And how would you do the same for constructors ?!? Create a
initWithStringIntegerSampleClassBoolean method which has to be called after
object creation ?!?
-Ursprüngliche Nachricht-
Von: Christian Schneider [mailto:[EMAIL PROTECTED]
Gesendet: Di 16.10.2007 11:45
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Hans Moog wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath(string $arg) {
return new DomXPath($this-loadXML($arg));
}
==
function xpathFromDom($arg) {
return new DomXPath($arg);
}
function xpathFromTree($arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpathFromString($arg) {
return new DomXPath($this-loadXML($arg));
}
Works perfectly well. And you don't even need to document them because
the names speak for themselves. A much simpler (and clearer) solution IMHO.
If you want an OO way I'd prefer something like
$xpath = $obj-getXPath();
to
$xpath = $this-xpath($obj);
anyway. This doesn't work with basic types like strings but having a
special case there is not a problem IMHO as using those two
interchangeably will lead to other problems anyway.
- Chris
AW: AW: AW: [PHP-DEV] Method overloading by method signature
And if you have more than one parameter you will name it methodFromStringIntegerSampleClassBoolean ?!? No, I would rethink my interface. Sometimes you need more than one parameter and even rethinking wouldn't solve this requirement. And how would you do the same for constructors ?!? Create a initWithStringIntegerSampleClassBoolean method which has to be called after object creation ?!? No, I would either use factory methods or the OO approach I outlined in my previous message. O_O really?!? You would use factory methods just to allow more than one parameter to be passed to the constructor? Oka. But let's agree that we fundamentally disagree on style. Yup :) I think you're using the wrong language but that's just me Over and out, - Chris I agree. But PHP (until PHP 5.2.x) was the wrong language for everyone who wanted to use namespaces, too. But a programming language is able to evolve and sometimes new features are really usefull and should be included. And in this special case the new feature would not harm anyone because it would be fully backward compatible and in my humble opinion it would push php to an enterprise level when it comes to object orientation. Btw: I really LOVE PHP and the way it handles things. You are able to develop applications VERY fast but when it comes to big applications it is sometimes better to be more strict and structure things a little bit different, especially when you have to mess around with 3rdparty developers.
RE: AW: AW: AW: [PHP-DEV] Method overloading by method signature
The point is that I do not see this feature at all relevant to solving the web problem. This is where PHP needs to focus. Namespaces help in solving the web problem, because it eases cooperation of independent developers to supply libraries. The feature you are proposing is solved easily in userland (just like named parameters). Its is a feature I could see using in a heavy lifting language, but not in a glue language. Where do we draw the line? Somewhere relatively arbitrary, but my gut tells me that this is a good candidate to be on lets leave it out of php side of the line. regards, Lukas When it comes to interoperation between systems and or developers, it is always a good idea to define strict standards of how the communication between libarys and components has to take place (since public methods are something like an interface bewteen interoperating libraries and classes), to be sure that all components work together as expected. One of the best approaches to explain the usage of the class to a foreign developer and to be sure that your class is used correctly and help the foreign developer to understand how your classes have to be used (beside documentation), is to typehint your parameters. But when you do so, you are no longer able to overload your methods anymore. Because of this, I think this feature is EXTREMELY relevant to solving the web problem. Not being able to overload methods anymore is a bad thing since overloaded methods allow to use a class in much more situations than just being able to use it in one single way. You are not able to tell the developer to use integer OR string values but NO arrays, booleans, Objects and so on when calling your method. You could mention it in the comment but when he misunderstands the comment, php doesn't notify him about his error. When using type hinted parameters, php would do so. You are not able to provide strict api's out of the box right now. You will always have to check the types of the passed parameters manually.
AW: [PHP-DEV] Method overloading by method signature
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath(string $arg) {
return new DomXPath($this-loadXML($arg));
}
==
(since when method overloding by sigantures wer put into php, scalar types
should be possible, too, shouldn't they?)
I would prefer the second one because I understand the behaviour much faster
than analyzing the if switch (and this if switch is really simple to understand
because there is only one command in every block). The second reason for me to
select the second version is, that I am able to write better documentation for
each behaviour (although, in this situation there isn't that much to be
commented).
-Ursprüngliche Nachricht-
Von: Timm Friebe [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 15. Oktober 2007 20:47
An: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hi,
[...]
Later we added type hints to help code readability.
Let me jump at this:
==
function xpath($arg) {
if ($arg instanceof DomDocument) {
return new DomXPath($arg);
} else if ($arg instanceof XmlTree) {
return new DomXPath($this-loadXML($arg-getSource()));
} else if (is_string($arg)) {
return new DomXPath($this-loadXML($arg));
} else {
throw new IllegalArgumentException('Unsupported argument type');
}
}
== vs. ==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath($arg) { // Untyped = default
if (!is_string($arg)) {
throw new IllegalArgumentException('Unsupported argument type');
}
return new DomXPath($this-loadXML($arg));
}
==
If we consider the readability argument only: Which one of the above more
readable? You decide:)
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Method overloading by method signature
As long as you only got one method per name it doesn't change things, so it
wouldn't brake backward compatibility and old functions would still behave like
expected (so it is not incompatible).
But if you want to be more strict and limit the coder to use your functions
only with a specific parameter signature (and thats the only reason to use type
hints - to ensure the method is used correctly and build more robust
applications), it is better to tell the coder that he made a mistake than just
going on and guessing which method to call.
The new PHP5 object model introduces signature checking (yay!) but since PHP
doesn't allow overloading a great deal of flexibilty was lost in this move
(boo!). No longer can you override a method provide an incompatible
signature. This mixture of strict OO + PHP's traditional loose typing is really
shooting PHP in the foot.
I think, that this ist the reason why nearly nobody uses this great new feature
(to ensure that the passed parameters are correct), because when he does, he
isn't able to provide different ways to use a method anymore.
And allowing signature checks would really enhance php's security because an
integer id (for example) can never be used to insert malicious sql into an sql
statement and by that create an sql injection.
You wouldn't have to put a mysql_escape_string (or integer typecast) around
every single parameter anymore because you would be able to rely on an integer
id, really being an integer id without messing around with thousands of custom
checks (that would even boost performance since string operations are always a
bit slow).
And like i already said - this new feature wouldn't make php a strong typed
language (you would still have all the possibilities of using variables as
different types), it would just offer the coder a method to write more strict
method declarations that would definitly enhance the performance, security an
robustness of applications.
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Oktober 2007 10:04
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
On 10/14/07, Hans Moog [EMAIL PROTECTED] wrote:
It shows an error that fun1 is not implemented for the signature of the
passed parameters.
But you could still provide a method that matches any number and type of
parameters by adding the following method declaration.
Well, this looks exactly like incompatibility to me, because currently
any function accepts any number of parameters (and you get
non-explicit ones by using func_get_args())
/**
* This method accepts parameters of any type and any count.
*/
public function fun1($parameters ...) {
/*
* array(3) {
* [0] = string(1) a
* [1] = string(2) b
* [2] = string(3) c
* }
*/
var_dump($parameters);
}
The ... notation (making it possible to have a dynamic count of parameters
of the given type (missing typehint automatically chooses mixed)) is only
allowed for the last parameter.
So method defintions like the following one are also possible:
public function fun1(string $firstParam, string $remainingParameters ...) {
/*
* string(1) a
*/
var_dump($firstParam);
/*
* array(3) {
* [0] = string(1) b
* [1] = string(2) c
* }
*/
var_dump($remainingParameters);
}
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 13. Oktober 2007 23:20
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
can your patch handle the following situation? how?
class A
{
public function fun1($a)
{
//…
}
public function fun1($a, $b)
{
//…
}
}
$a = new A();
$a-fun1('a', 'b', 'c'); // which method is called here?
On 10/14/07, Hans Moog [EMAIL PROTECTED] wrote:
Why would it be incompatible with php's dynamic nature? (I already heard
many people saying that this is not the php way) But why ? Don't you like
it or do you think it is just not possible to be implemented in php?
I could provide a patch that makes it possible (even with complete
visibility and inheritance rules). We already use it and it saves us a lot
of code.
I think it is better than the '$x = defaultValue' kind of way to accept
different count and types of parameters because it is MUCH more expressive
and intuitive.
It wouldn't even break backward compatibility beause it is just
syntactical sugar to checking the variable types manually and then
dispatching to the right behaviour.
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 13. Oktober 2007 22:22
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hans, such overloading would
RE: [PHP-DEV] Method overloading by method signature
I will do so, but i will have to modify it to work with the current php version
and I wanted to know if everybody hates this way of method overloading first.
Btw: We made some benchmark tests when we decided to use it. And the method
calls were about 0.1 Percent slower. But without having to check or escape
every parameter anymore it even boosts performance for us, since we really try
to build very robust applications and because of that check all parameters that
could be problematic.
But if you write quick and dirty code without thinking about sql injections or
other problems and not checking anyhting, it is definitly a bit slower (about
0.1 percent of a normal method call).
But I think this loss of performance is worth it since the current way of php's
mixture of strict OO + traditional loose typing is really shooting PHP in the
foot. (Nobody will ever really use typehinting when he want's to offer a number
of ways to use a method).
-Ursprüngliche Nachricht-
Von: Marcus Boerger [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Oktober 2007 09:29
An: Hans Moog
Cc: Alexey Zakhlestin; internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Hello Hans,
If you have such a patch you should definitively post it here so that we
can hve a look. Most interesting to us is however the oerformance impact. As
that was the main reason to go any further than adding return type hints.
marcus
Saturday, October 13, 2007, 10:47:23 PM, you wrote:
Why would it be incompatible with php's dynamic nature? (I already heard
many people saying that this is not the php way) But why ? Don't you
like it or do you think it is just not possible to be implemented in php?
I could provide a patch that makes it possible (even with complete
visibility and inheritance rules). We already use it and it saves us a lot of
code.
I think it is better than the '$x = defaultValue' kind of way to accept
different count and types of parameters because it is MUCH more expressive
and intuitive.
It wouldn't even break backward compatibility beause it is just
syntactical sugar to checking the variable types manually and then
dispatching to the right behaviour.
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 13. Oktober 2007 22:22
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hans, such overloading would be incompatible with php's dynamic nature
As far as I remember, even type-hinting for basic-types (strings,
integers) was rejected
On 10/13/07, Hans Moog [EMAIL PROTECTED] wrote:
Will method overloading by method signature be implemented in php6 or
even php 5.3?
Example:
?php
namespace xyz;
import core::TestClass;
class Test extends TestClass {
public string function test(integer $int) {
return Hi;
}
public integer function test(string $string, integer $int) {
return $int;
}
}
?
I think this would be a very big advantage and would help developers to
write better code.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Method overloading by method signature
You are missing something. Using this new feature would be voluntarily (it is
optional like type hints are already).
If you want to code the old way and you don't want to force coders to use your
functions correctly, you could leave out typehints an check the parameters
manually.
But if you want to write strict API's, that accept only a special type of
parameters (and type hinted parameters were introduced to be able to do this)
you would still be able to accept more than one type of parameters (without
this additional feature you are not able to do it right now).
You do not use type hints in your functions, thats why you don't understand the
need of overloding methods by parameter siganture. If you would understand the
need of type hints for robust applications you would understand the need of
overloading typehinted methods.
Btw: You could call foo((integer) $x); to ensure the right method is called.
Like I already said, this feature is only require for people writing complex
web applications, offering api's to 3rdparty coders that are very strict. If
you are coding a project within your company you can rely on the fact, that
programmers should know how to use your methods, but a 3rdparty coder who
extends the functionality of your product doesn't know and there should be no
chance to crash the application.
-Ursprüngliche Nachricht-
Von: Christian Schneider [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Oktober 2007 14:27
An: Marcus Boerger
Cc: internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Marcus Boerger wrote:
If you have such a patch you should definitively post it here so that we
can hve a look. Most interesting to us is however the oerformance impact. As
that was the main reason to go any further than adding return type hints.
Am I the only here who thinks that performance is not the major issue
with this approach?
Method signatures lead to a different style of programming I personally
wouldn't want to encourage in PHP.
I'm expecting some kind of if you don't like it don't use it answer
but I wouldn't want to bloat the language for such a feature anyway.
Example:
It's too easy for someone to think it's a good idea to change
function foo($x) { ... }
to something like
function foo(string $x) { ... }
function foo(int $x) { ... }
but this can lead to very subtle bugs as automatic type conversion can
trick you into passing something different than you thought and hence
could lead you to do
foo(strval($x));
all over the place to not get any surprises. A Bad Thing(TM) IMHO.
Regards,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Method overloading by method signature
Kcachegrind doesn't show the function signature in the callgraph because the
parameter signature is not part of the function signature. If the parameter
siganture would be moved into the function signature, kcachegrind would adept
and show it.
Btw: You don't have to use it if you don't want to. But PHP5 didn't include
type hints for no reason. The problem: Type hints don't make many sense right
now.
Like I already wrote in another comment. If you would use type hints you would
understand the need of overloading type hinted methods.
-Ursprüngliche Nachricht-
Von: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 14. Oktober 2007 16:50
An: Christian Schneider
Cc: Marcus Boerger; internals@lists.php.net
Betreff: Re: AW: [PHP-DEV] Method overloading by method signature
Christian Schneider wrote:
Marcus Boerger wrote:
If you have such a patch you should definitively post it here so
that we
can hve a look. Most interesting to us is however the oerformance
impact. As
that was the main reason to go any further than adding return type hints.
Am I the only here who thinks that performance is not the major issue
with this approach?
Method signatures lead to a different style of programming I personally
wouldn't want to encourage in PHP.
I'm expecting some kind of if you don't like it don't use it answer
but I wouldn't want to bloat the language for such a feature anyway.
Example:
It's too easy for someone to think it's a good idea to change
function foo($x) { ... }
to something like
function foo(string $x) { ... }
function foo(int $x) { ... }
but this can lead to very subtle bugs as automatic type conversion can
trick you into passing something different than you thought and hence
could lead you to do
foo(strval($x));
all over the place to not get any surprises. A Bad Thing(TM) IMHO.
Yup, I agree. Having to sit and count arguments and figure out the
types in order to determine which actual method is being called makes it
damn near impossible to debug code as far as I am concerned. And what
does the callgraph from a profiler look like? kcachegrind doesn't show
the function signature in the callgraph which means we would have to map
these methods to some unique name and people would have to know how to
map these names back to the correct function signature. Sounds like a
mess to me.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Method overloading by method signature
Will method overloading by method signature be implemented in php6 or
even php 5.3?
Example:
?php
namespace xyz;
import core::TestClass;
class Test extends TestClass {
public string function test(integer $int) {
return Hi;
}
public integer function test(string $string, integer $int) {
return $int;
}
}
?
I think this would be a very big advantage and would help developers to
write better code.
AW: [PHP-DEV] Method overloading by method signature
Why would it be incompatible with php's dynamic nature? (I already heard many
people saying that this is not the php way) But why ? Don't you like it or do
you think it is just not possible to be implemented in php?
I could provide a patch that makes it possible (even with complete visibility
and inheritance rules). We already use it and it saves us a lot of code.
I think it is better than the '$x = defaultValue' kind of way to accept
different count and types of parameters because it is MUCH more expressive and
intuitive.
It wouldn't even break backward compatibility beause it is just syntactical
sugar to checking the variable types manually and then dispatching to the
right behaviour.
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 13. Oktober 2007 22:22
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hans, such overloading would be incompatible with php's dynamic nature
As far as I remember, even type-hinting for basic-types (strings,
integers) was rejected
On 10/13/07, Hans Moog [EMAIL PROTECTED] wrote:
Will method overloading by method signature be implemented in php6 or
even php 5.3?
Example:
?php
namespace xyz;
import core::TestClass;
class Test extends TestClass {
public string function test(integer $int) {
return Hi;
}
public integer function test(string $string, integer $int) {
return $int;
}
}
?
I think this would be a very big advantage and would help developers to
write better code.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
RE: [PHP-DEV] Method overloading by method signature
It shows an error that fun1 is not implemented for the signature of the passed
parameters.
But you could still provide a method that matches any number and type of
parameters by adding the following method declaration.
/**
* This method accepts parameters of any type and any count.
*/
public function fun1($parameters ...) {
/*
* array(3) {
* [0] = string(1) a
* [1] = string(2) b
* [2] = string(3) c
* }
*/
var_dump($parameters);
}
The ... notation (making it possible to have a dynamic count of parameters of
the given type (missing typehint automatically chooses mixed)) is only allowed
for the last parameter.
So method defintions like the following one are also possible:
public function fun1(string $firstParam, string $remainingParameters ...) {
/*
* string(1) a
*/
var_dump($firstParam);
/*
* array(3) {
* [0] = string(1) b
* [1] = string(2) c
* }
*/
var_dump($remainingParameters);
}
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 13. Oktober 2007 23:20
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
can your patch handle the following situation? how?
class A
{
public function fun1($a)
{
//…
}
public function fun1($a, $b)
{
//…
}
}
$a = new A();
$a-fun1('a', 'b', 'c'); // which method is called here?
On 10/14/07, Hans Moog [EMAIL PROTECTED] wrote:
Why would it be incompatible with php's dynamic nature? (I already heard many
people saying that this is not the php way) But why ? Don't you like it or
do you think it is just not possible to be implemented in php?
I could provide a patch that makes it possible (even with complete visibility
and inheritance rules). We already use it and it saves us a lot of code.
I think it is better than the '$x = defaultValue' kind of way to accept
different count and types of parameters because it is MUCH more expressive
and intuitive.
It wouldn't even break backward compatibility beause it is just syntactical
sugar to checking the variable types manually and then dispatching to the
right behaviour.
-Ursprüngliche Nachricht-
Von: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 13. Oktober 2007 22:22
An: Hans Moog
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] Method overloading by method signature
Hans, such overloading would be incompatible with php's dynamic nature
As far as I remember, even type-hinting for basic-types (strings,
integers) was rejected
On 10/13/07, Hans Moog [EMAIL PROTECTED] wrote:
Will method overloading by method signature be implemented in php6 or
even php 5.3?
Example:
?php
namespace xyz;
import core::TestClass;
class Test extends TestClass {
public string function test(integer $int) {
return Hi;
}
public integer function test(string $string, integer $int) {
return $int;
}
}
?
I think this would be a very big advantage and would help developers to
write better code.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
