Hello Hans, Sunday, October 14, 2007, 1:11:35 PM, you wrote:
> 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). Reading this it occurs to me that you are on a completely wrong track. PHP is untyped for a good reason. It was a choice to deal with the untyped web environment. Later we added type hints to help code readability. Yet OOP is only a small apspect of PHP and always will be. That said the language for you would probably have another one. Also type hinting and overloading do not in any way free you from filtering and escaping. If you think so you may test your code again and hopefuly not find too many security holes. The reason I asked for performance impact is that in general we do not like to add features that are not necessary for the web environment but have a negative impact on it. Also reading of an impact of 0.1 percent seems very strange as basically anything below 2% is close to the measurable limit and the onlt way to measure such tiny impacts would be counting assembled instructions using callgrind. Last but not least we added typehints to enable developers to generate better understandable error messages. These go especially well with the typical easy PHP application designs and PHPs stack trace ability in exception handling. marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
