Case insensitivity weakened the power of overloading

php.internals

Wei He

23 years ago
Hi, Besides in-php use of class method/property overloading, XML-RCP can be a perfect application of this functionality. But again it touchs the sensitive topic of case sensitivity of Zend. With CS, an RPC call will be $rpcclient->methodname($arg1, $arg2); instead of $rpcclient->call($methodname, $arg1, $arg2); SOAP'w workaround of collecting all available methods is efficient and sometime not support by all XML-RPC servers. Especially when the method is also a dynamic call on the server side. Think of a Python(Zope) XML-RPC server. As Zend Engine 2 can change the world such a lot, why not just a little bit on class/method/function name's case sensitivity? When I am wriing this message, I'm compiling my PHP with CS patch. I noticed, besides some internal places like Zend, aggregate and overload need to be patched, the bundled PEAR also need to be patch to at least make the RPM buildable. I also saw how the author hates case insensitivities, so I'm not afraid of posting this issue again. Please give me some reasons why not. How about in Zend Engine 2? Wei He

Zeev Suraski

23 years ago
Please read the archives, that's definitely a thread we don't need to reopen. At 15:07 18/05/2003, Wei He wrote:

Jani Taskinen

23 years ago
On Sun, 18 May 2003, Zeev Suraski wrote:
>Please read the archives, that's definitely a thread we don't need to reopen.
Why not? It was again one of those discussions where everyone else were +1 and you just killed it. :-p --Jani
>At 15:07 18/05/2003, Wei He wrote: >>Hi, >> >>Besides in-php use of class method/property overloading, >>XML-RCP can be a perfect application of this functionality. >> >>But again it touchs the sensitive topic of case sensitivity of Zend. >> >>With CS, an RPC call will be >> >>$rpcclient->methodname($arg1, $arg2); >> >>instead of >> >>$rpcclient->call($methodname, $arg1, $arg2); >> >>SOAP'w workaround of collecting all available methods >>is efficient and sometime not support by all XML-RPC servers. >>Especially when the method is also a dynamic call on the >>server side. Think of a Python(Zope) XML-RPC server. >> >>As Zend Engine 2 can change the world such a lot, why not just >>a little bit on class/method/function name's case sensitivity? >> >>When I am wriing this message, I'm compiling my PHP with CS patch. >>I noticed, besides some internal places like Zend, aggregate and overload >>need to be patched, the bundled PEAR also need to be patch to at least >>make the RPM buildable. >> >>I also saw how the author hates case insensitivities, so I'm not afraid >>of posting this issue again. >> >>Please give me some reasons why not. How about in Zend Engine 2? >> >>Wei He >> >> >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php > > >
-- <- For Sale! ->

Wei He

23 years ago
On Sun, 18 May 2003, Zeev Suraski wrote:
> Please read the archives, that's definitely a thread we don't need to reopen.
I have read excatly the same suggestion in the archive on http://marc.theaimsgroup.com but not the definitely-should-exist thread. Would you show me those posts please? Wei He

Zeev Suraski

23 years ago
At 15:51 18/05/2003, Jani Taskinen wrote:
>On Sun, 18 May 2003, Zeev Suraski wrote: > > >Please read the archives, that's definitely a thread we don't need to > reopen. > > Why not? It was again one of those discussions where everyone > else were +1 and you just killed it. :-p
Jani, I'm personally sick and tired of living my life in a loop. Yes, there are certain issues where there's a bunch of people on internals@ that would like to see things changed, and you know what, they won't. Why? Because that's the way they used to be, that's the way they were when you joined the project, and those that forged this project believe that they're key factors to the project's success, or that changing them would seriously hurt the project in general. A fundamental issue like case sensitivity falls in that category. So does the decision to bundle key libraries, a decision reached by the PHP Group in January 2000. When you joined the project, you acknowledged it was something you were willing to live with. The fact that people who care about these things are already fed up with discussing them again and again, and that there are random majorities on internals@ against them, is NOT going to change it. As I said once, when is it time to end the discussion? Once we reach a decision that *you* are happy with? Before you answer "Yes! :)", the answer is no! Zeev

Wei He

23 years ago
> > I'm personally sick and tired of living my life in a loop. Yes, there are > certain issues where there's a bunch of people on internals@ that would > like to see things changed, and you know what, they won't. Why? Because > that's the way they used to be, that's the way they were when you joined > the project, and those that forged this project believe that they're key > factors to the project's success, or that changing them would seriously > hurt the project in general.
I can understand the feeling. But I don't think it is the right way that once a decision is made, it has to be follow for 1000 years. Regardig this issue, why not create a check list on the web, showing all the reasons to do and not to do. As the world is changing, one day people might aggree to be on one side or another. I think this is at least a better way to pull your life out of the loop. :) For PHP's success, I don't think it is because keeping things unchanged. On the country, the evolution is the key. Why I have spent 6+ years developing on PHP and have coded several hundreds of classes? Why not just go JAVA and forget the countless walkaronds on passing class instances by reference? Why not just stay on Zope rather than try to connect PHP to Zope? And I'm sure there are stronger reasons for other PHP lovers. Look at PHP's evolution, there are many big behavior changes affecting current codes. Some are important like register global vars and some IMO are unnecessary like calltime pass references. All these changes are trying to change the programmers' coding habit. And I don't think a single one of them will become angry on this (at the most, upset a little bit). I can see Zend Engine 2 has more problems regarding changing what it currently is. Like the function namespace. I have to go through my projects to rename Foo::count() to avoid otherwise unwanted effect when counting arrays. What my impression is, as this can be change, why not case sensitivity? Are there still someone object CS on this list besides you whose reason is a decision made 3 years ago?
> A fundamental issue like case sensitivity falls in that category. So does > the decision to bundle key libraries, a decision reached by the PHP Group > in January 2000. When you joined the project, you acknowledged it was > something you were willing to live with. > The fact that people who care about these things are already fed up with > discussing them again and again, and that there are random majorities on > internals@ against them, is NOT going to change it. As I said once, when > is it time to end the discussion? Once we reach a decision that *you* are > happy with? Before you answer "Yes! :)", the answer is no!
Will the changed behaviors like register global vars still lead to discussions? Sorry, I don't mean to give you, the one in such a sensitive position, any pressure. (Can this because CS will affect Zend's commercial products much more than end users' codes?) I can patch PHP myself and share it with any other one likes it. Just I want to know the reason not doing CS. Be relax, everyone. :) Wei He

James Cox

23 years ago
> > For PHP's success, I don't think it is because keeping things unchanged. > On the country, the evolution is the key. Why I have spent 6+ years > developing on PHP and have coded several hundreds of classes? > Why not just go JAVA and forget the countless walkaronds on passing > class instances by reference? Why not just stay on Zope rather than try > to connect PHP to Zope? And I'm sure there are stronger reasons for other > PHP lovers. >
if you want proper OO, Nesting, and other Java style features, use java. If you want a powerful template engine that can do neat tricks and makes building a website easier, use PHP. -- james

Wei He

23 years ago
On Sun, 18 May 2003, James Cox wrote:
> if you want proper OO, Nesting, and other Java style features, use java. If > you want a powerful template engine that can do neat tricks and makes > building a website easier, use PHP. >
I want both. And even more: XML/XSLT, XML-RPC and many other interesting functions all in the simple platform of PHP. I don't see anything prevents PHP from being one of the best OO programming tools. Even Zend 1, =& =& =& ... I don't care. :) Wei He

Zeev Suraski

23 years ago
At 16:29 18/05/2003, Wei He wrote:
>Just I want to know the reason not doing CS.
Simply put, backwards compatibility. If PHP was released today, it would have been case sensitive. And yes, there are plenty of other people, some on this list and many that aren't, that object to going to case sensitivity because of this reason exactly. By the way, if what you worry about is bridging with external object models like Java, COM or GTK - you don't have to worry. Only PHP objects are case insensitive. The OO overloading layer in ZE2 supports case-sensitive method calls. Zeev

Wei He

23 years ago
On Sun, 18 May 2003, Zeev Suraski wrote:
> At 16:29 18/05/2003, Wei He wrote: > > >Just I want to know the reason not doing CS. > > Simply put, backwards compatibility. If PHP was released today, it would > have been case sensitive. And yes, there are plenty of other people, some > on this list and many that aren't, that object to going to case sensitivity > because of this reason exactly.
So it does? Then as I think PHP's backwards compatibilty records really needed to be criticized. A more item won't make it worse. :) Even though there are better ways of doing this rather than lowercasing all class/function names before adding to the hash. As least __call should have been able to get the case-sensitive method name. IMO it's quire unnecessary to close the CS thread.
> By the way, if what you worry about is bridging with external object models > like Java, COM or GTK - you don't have to worry. Only PHP objects are case > insensitive. The OO overloading layer in ZE2 supports case-sensitive > method calls.
That sounds good to me. But I still suggest being CS in ZE2 even for PHP objects. There is a Chinese saying, better short pain than a longer one. You can just go ahead to do CS in ZE2. Nobody will die of it and only PHP becomes more mature. Best, Wei He

Zeev Suraski

23 years ago
At 17:31 18/05/2003, Wei He wrote:
>IMO it's quire unnecessary to close the CS thread.
Oh, but it is. Zeev