Re: AW: [PHP-DEV] 4.1 Declaration Case Persistance
On Wed, 9 May 2001, Sterling Hughes wrote: On Thu, 10 May 2001, Jani Taskinen wrote: This is just because some developers don't like to follow the guidelines. As, I quote, it woulnd't be fun anymore or you can't force anyone. Hrrmmm.. Which guidelines would those be? And no, you can't force anyone, This one.. (from CODING_STANDARDS): 8--- Naming Conventions -- [1] Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words 8--- And yes, you can force anyone. If they don't follow the guidelines set, their CVS access can as easily be taken from them as it was given.. This is same as if someone intentionally breaks some parts of the code. if you see something you don't like however, your welcome to change it, and if its generally a good change, then it will be included in the code. So..you think that if you are lazy and don't wanna follow these loose guidelines a bit and use your own intendation and naming convention someone else has to come after and clean up your mess?! Yeah, right. This isn't like at your home where your mom cleans up your room. Here you really have to do it yourself. :-p I've gone ahead and changed them all to lower case... If its a bad change I'm expecting people to bitch. Anyone good with regexps could create a script which could be used to at least find these..or even convert them to lower case ? another question: according to the CODING_STANDARDS file every function should be lowercase, but how about exported classes ? is there a guidline for this ? See above. There is no standard in the CODING_STANDARDS file. So why does it even exist? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: AW: [PHP-DEV] 4.1 Declaration Case Persistance
On Thu, 10 May 2001, Jani Taskinen wrote: On Wed, 9 May 2001, Sterling Hughes wrote: On Thu, 10 May 2001, Jani Taskinen wrote: This is just because some developers don't like to follow the guidelines. As, I quote, it woulnd't be fun anymore or you can't force anyone. Hrrmmm.. Which guidelines would those be? And no, you can't force anyone, This one.. (from CODING_STANDARDS): 8--- Naming Conventions -- [1] Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words 8--- And yes, you can force anyone. If they don't follow the guidelines set, their CVS access can as easily be taken from them as it was given.. This is same as if someone intentionally breaks some parts of the code. How is this helpful? By removing CVS access your taking one person away who could possibly solve the problem. And your still not forcing them to do anything. If I was a new developer and someone removed my CVS access because I goofed up, or my code didn't conform to the CODING_STANDARDS file, I would most likely not contribute again, and would not be happy with the PHP development team. If we send people away its usually not their loss, but rather ours (exceptions can be made for a few people, *cough* Jon Ribbens *cough* ;) if you see something you don't like however, your welcome to change it, and if its generally a good change, then it will be included in the code. So..you think that if you are lazy and don't wanna follow these loose guidelines a bit and use your own intendation and naming convention someone else has to come after and clean up your mess?! Yeah, right. If someone has a problem with the way I or someone else codes, they're more than welcome to fix it themselves. While in a perfect world all files and pieces of work would fit into PHP perfectly, that isn't so. There's no reason to look down upon good pieces of code, because the identation doesn't match the PHP standard, or they don't name things according to the standard. If its really that big a problem, ask the developer to fix it, and if they don't want too, fix it yourself (I mean yourself in the general sense), or leave it alone. This isn't like at your home where your mom cleans up your room. Here you really have to do it yourself. :-p That was only in Italy :) And damn that was great, I got three fresh cooked meals a day too, as well as all my laundry done, a, but I digress. I've gone ahead and changed them all to lower case... If its a bad change I'm expecting people to bitch. Anyone good with regexps could create a script which could be used to at least find these..or even convert them to lower case ? I think the com extension was the last remnants, grep could easily handle this... another question: according to the CODING_STANDARDS file every function should be lowercase, but how about exported classes ? is there a guidline for this ? See above. There is no standard in the CODING_STANDARDS file. So why does it even exist? Maybe you mis-understood me. I mean there is no written standard for the naming of classes in the CODING_STANDARDS file, not that the CODING_STANDARDS file is not to be followed (or changed if a part of it is objectionable ;) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: AW: [PHP-DEV] 4.1 Declaration Case Persistance
At 06:46 10/5/2001, Harald Radi wrote: looking forward to getting php case sensitive i'm just wondering that function names are exported mixed case in the com extension. e.g. there's a COM_load() and a com_set(), is there a special reason for this (zeev) ? There's no special reason, and it's going to be fixed ifwhen we switch to case sensitivity (right now the declaration doesn't really matter). At any rate, to match the standards file, I'll fix it to be lowercase. another question: according to the CODING_STANDARDS file every function should be lowercase, but how about exported classes ? is there a guidline for this ? No guidelines yet. I'm sure we'll work on them when it becomes relevant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: AW: [PHP-DEV] 4.1 Declaration Case Persistance
Sterling Hughes [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED]... On Thu, 10 May 2001, Jani Taskinen wrote: On Wed, 9 May 2001, Sterling Hughes wrote: On Thu, 10 May 2001, Jani Taskinen wrote: This is just because some developers don't like to follow the guidelines. As, I quote, it woulnd't be fun anymore or you can't force anyone. Hrrmmm.. Which guidelines would those be? And no, you can't force anyone, This one.. (from CODING_STANDARDS): 8--- Naming Conventions -- [1] Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words 8--- yea, but i wasn't talking about functions, i was talking about classes (in particular the com, dotnet and variant class). i couldn't find a guidline how to name classes, attributes or methods. there is even no guidline in the PEAR CODING_STANDARDS file, but they use a more c++ like convention: CLASS-lowerUpperUpper(); should this be adopted to have an uniform convetion ? any other ideas ? and at least, how should they be documented in the php documentation (i posted a mail 2 days ago, but without response) ? afaik there is only a function/function tag, but no class/class, member/member, method/method, constructor/constructor, etc. tags. any suggestions ? And yes, you can force anyone. If they don't follow the guidelines set, their CVS access can as easily be taken from them as it was given.. This is same as if someone intentionally breaks some parts of the code. i didn't want to blame someone, the reason i asked was, that the com extension was originaly done by zeev, so i thought there was a reason for the naming. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: AW: [PHP-DEV] 4.1 Declaration Case Persistance
On Thu, 10 May 2001, Harald Radi wrote: looking forward to getting php case sensitive i'm just wondering that Me too. function names are exported mixed case in the com extension. e.g. there's a COM_load() and a com_set(), is there a special reason for this (zeev) ? This is just because some developers don't like to follow the guidelines. As, I quote, it woulnd't be fun anymore or you can't force anyone. another question: according to the CODING_STANDARDS file every function should be lowercase, but how about exported classes ? is there a guidline for this ? See above. --Jani harald. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Chuck Hagenbuch Gesendet: Freitag, 04. Mai 2001 21:10 An: [EMAIL PROTECTED] Betreff: Re: [PHP-DEV] 4.1 Declaration Case Persistance Quoting Colin Viebrock [EMAIL PROTECTED]: One problem with case sensitivity (perhaps) is that it may make some scripts non-portable. That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. -chuck -- must... find... acorns... *thud* -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: AW: [PHP-DEV] 4.1 Declaration Case Persistance
On Thu, 10 May 2001, Jani Taskinen wrote: On Thu, 10 May 2001, Harald Radi wrote: looking forward to getting php case sensitive i'm just wondering that Me too. function names are exported mixed case in the com extension. e.g. there's a COM_load() and a com_set(), is there a special reason for this (zeev) ? This is just because some developers don't like to follow the guidelines. As, I quote, it woulnd't be fun anymore or you can't force anyone. Hrrmmm.. Which guidelines would those be? And no, you can't force anyone, if you see something you don't like however, your welcome to change it, and if its generally a good change, then it will be included in the code. I've gone ahead and changed them all to lower case... If its a bad change I'm expecting people to bitch. another question: according to the CODING_STANDARDS file every function should be lowercase, but how about exported classes ? is there a guidline for this ? See above. There is no standard in the CODING_STANDARDS file. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 05:01 PM 5/3/2001 -0400, John Donagher wrote: We use a Java-style methodology of naming classes as well as filenames, something we've adopted largely because of our use of PHPDoc. So, if you have a class FooBar, that class is defined in FooBar.cls, not foobar.cls. If get_class() returned the as-declared name, we'd have a really easy way to know where that class was defined. When you start getting into complex inheritance and class dependency trees, this issue finally rears its head. Other than this case, I have never cared. So, I've had to create a code generator to build a structure containing a mapping of class declaration names pointing back to filenames, which otherwise could not be accurately programatically determined. But if you use lowercased class naming, you can programatically determine the filename. That seems wrong to me. We (at my current company) have a clean architecture, something we're working on incorporating into a currently existing open-source application framework project to allow other people to use. So yes, three users may be affected by it now (maybe less :). I really don't want to propogate the kludge I've had to write out to hundreds of people, though. On one hand you might feel it odd on the other hand it might be odd to a developer who knows that classes are case insensitive and when he users your framework then he will suddenly discover (or not discover) that writing FooBar is different from foobar, i.e., they need to know that when using your framework that they need to watch their case and that it is unlike any other PHP script or framework. OK that was a too long sentence (I'm on the way out) but do you understand that it has implications on the developer who is used to case-insensitive classes and doesn't watch his case. Don't change the code because of me, or because of the project I'm working on, or because of the way PHPDoc works. We've already worked around it. But I still maintain that tossing away the declared names is not the only (or the best) way to achieve case-insensitivity in the language. Believe me, I wouldn't have wasted cycles thinking/writing about this if I wasn't convinced it will benefit PHP and its users in the long run, even if the value add is relatively minor. Can you describe your workaround? Think of what I have written. I doubt it'll convince you but you should realize that PHP has case insensitive-classes but your framework will have classes which are case-sensitive. Does this make sense? It means the people who will be using your open-framework will almost be using a different PHP. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I don't know enough about Zend internals to speak with any authority, but wouldn't an easy way of doing this be to: a) store *only* the mixed case version of the class name in the hash table, and b) change get_class(), etc. so that they automatically pass the result through strtolower() (or whatever) first ... unless the optional second argument is passed, in which case it's just returned as is. You wouldn't need a bigger nor an additional hash table, AFAICT, and only what I imagine is relatively minor code changes to the get_class(), etc. functions. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On Fri, 4 May 2001, Colin Viebrock wrote: I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I don't know enough about Zend internals to speak with any authority, but wouldn't an easy way of doing this be to: a) store *only* the mixed case version of the class name in the hash table, and b) change get_class(), etc. so that they automatically pass the result through strtolower() (or whatever) first ... unless the optional second argument is passed, in which case it's just returned as is. You wouldn't need a bigger nor an additional hash table, AFAICT, and only what I imagine is relatively minor code changes to the get_class(), etc. functions. Not really, the class name's are stored in lowercase, for case-insensitive lookups, therefore, every single time the engine needs to look up the class name it would need to convert the case of the class name to lower case. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
The question was under what key the class entry should be stored... At any rate, it's a non-issue; Saving the 'beautiful' version of the class name is possible, but is a bit hacky IMHO. There should be an optional case sensitive mode, and we'll introduce one in one of the future versions of PHP. Zeev At 18:04 4/5/2001, Colin Viebrock wrote: I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I don't know enough about Zend internals to speak with any authority, but wouldn't an easy way of doing this be to: a) store *only* the mixed case version of the class name in the hash table, and b) change get_class(), etc. so that they automatically pass the result through strtolower() (or whatever) first ... unless the optional second argument is passed, in which case it's just returned as is. You wouldn't need a bigger nor an additional hash table, AFAICT, and only what I imagine is relatively minor code changes to the get_class(), etc. functions. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Good work Zeev. It's for a good cause. Everyone else just seems to be whining... i don't wanna. Shaun On Fri, 4 May 2001, Zeev Suraski wrote: The question was under what key the class entry should be stored... At any rate, it's a non-issue; Saving the 'beautiful' version of the class name is possible, but is a bit hacky IMHO. There should be an optional case sensitive mode, and we'll introduce one in one of the future versions of PHP. Zeev At 18:04 4/5/2001, Colin Viebrock wrote: I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I don't know enough about Zend internals to speak with any authority, but wouldn't an easy way of doing this be to: a) store *only* the mixed case version of the class name in the hash table, and b) change get_class(), etc. so that they automatically pass the result through strtolower() (or whatever) first ... unless the optional second argument is passed, in which case it's just returned as is. You wouldn't need a bigger nor an additional hash table, AFAICT, and only what I imagine is relatively minor code changes to the get_class(), etc. functions. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
The question was under what key the class entry should be stored... At any rate, it's a non-issue; Saving the 'beautiful' version of the class name is possible, but is a bit hacky IMHO. There should be an optional case sensitive mode, and we'll introduce one in one of the future versions of PHP. Yeah ... I posted before reading the remainder of the thread. :) One problem with case sensitivity (perhaps) is that it may make some scripts non-portable. Say I develop a super-duper PEAR class using case-sensitive code (cause that's what I have on my server). Someone who is running PHP in case-insensitive mode will complain when my code says: if (get_class($foo)=='Some_Class_Name')) { ... So all code that might be shared either a) needs to only us lowercase names, b) coders need to implicity lowercase their comparisons by changing the above line to: if (strtolower(get_class($foo))=='some_class_name')) { ... or c) we also need a way to switch between sensitivity modes through PHP code (either an ini_set() call, or something else). Also, case-sensitivity means I can write code with functions like StrReplace() and MySQL_Fetch_Row(), which will seriously cause problems on non-case-sensitive installs ... unless all variations of PHP functions are reserved. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Quoting Colin Viebrock [EMAIL PROTECTED]: One problem with case sensitivity (perhaps) is that it may make some scripts non-portable. That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. -chuck -- must... find... acorns... *thud* -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On Fri, 4 May 2001, Chuck Hagenbuch wrote: Quoting Colin Viebrock [EMAIL PROTECTED]: One problem with case sensitivity (perhaps) is that it may make some scripts non-portable. That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. +1 for that! :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On 2001-05-04 20:01:42, Colin Viebrock [EMAIL PROTECTED] wrote: One problem with case sensitivity (perhaps) is that it may make some scripts non-portable. Say I develop a super-duper PEAR class using case-sensitive code (cause that's what I have on my server). Someone who is running PHP in case-insensitive mode will complain when my code says: if (get_class($foo)=='Some_Class_Name')) { ... So why not make it plain that it will only run under PHP 4.1 with case-sensitivity enabled? The whole point is that it is a compatibility breaking change, and the case sensitivity switch is really only there to help migrate legacy code. Just my HO. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Sterling Hughes [EMAIL PROTECTED] wrote: On Fri, 4 May 2001, Chuck Hagenbuch wrote: That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. +1 for that! :) +1 --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
1++; Wez Furlong [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Sterling Hughes [EMAIL PROTECTED] wrote: On Fri, 4 May 2001, Chuck Hagenbuch wrote: That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. +1 for that! :) +1 --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Guys, We're not holding votes about this stuff. Definitely not now. Without trying to initiate a discussion, please bear in mind that if we break compatibility completely, we're screwing companies that chose PHP. It'll put PHP in a very unprofessional light. Food for thought; We're way too far away from this to even discuss it. Zeev At 22:51 4/5/2001, Wez Furlong wrote: Sterling Hughes [EMAIL PROTECTED] wrote: On Fri, 4 May 2001, Chuck Hagenbuch wrote: That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. +1 for that! :) +1 --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.1 Declaration Case Persistance
Hi folks- I brought this up a few months ago, and due to either tacid approval or utter disinterest I was unable to spark a discussion or gather a concensus :) Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. This provides the case-insensitivity that PHP has, but it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. This has a rather narrow end-user meaning for most people, but not for teams like ours who structure their code with cased filenames. The current implementation can be worked-around, I'm just not sure I see any advantage of lowercasing the declarative as opposed to just maintaining a hash of lowercase = as_declared. That would still allow for case-insensitivity while allowing the reverse-lookup functions to be more correct. Any opinions? Have I overlooked something that makes this more difficult than it seems? I'm willing to work on this if I can gather some positive concensus. -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Any opinions? Have I overlooked something that makes this more difficult than it seems? I'm willing to work on this if I can gather some positive concensus. For one thing, I would have to change all my code from: if (get_class($var)=='foo_class')) { ... } ... to: if (get_class($var)=='Foo_Class')) { ... } ... (assuming I know how it was declared), or to: if (strtolower(get_class($var))=='foo_class')) { ... } ... which I personally think is kludgy. Ditto for function_exists(), I assume. Or are you suggesting something like: getOriginalDeclaredName('foo_class');// returns 'Foo_Class'; ... which I don't have a problem with, I suppose. Then again, I don't write the Zend code. :) I don't follow how having the full case of the original declaration would help you. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
| John Donagher [EMAIL PROTECTED] Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. +1 It will work, right (zend guys?). I'd love to see it. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On 2001-05-03 22:51:41, Wez Furlong [EMAIL PROTECTED] wrote: | John Donagher [EMAIL PROTECTED] Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. +1 It will work, right (zend guys?). I'd love to see it. I just read Colins comments (but deleted the message already!). OK, so +1 to get_declared_class() which returns the class name with original case preserved. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On Thu, 03 May 2001, Wez Furlong wrote: I just read Colins comments (but deleted the message already!). OK, so +1 to get_declared_class() which returns the class name with original case preserved. Umm, that sounds kind of arbitrary. There could be an optional parameter to get_class(), get_parent_class(), and others that specifies which class name to return. -Andrei * How would this sentence be different if Pi was equal to three? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On Thu, 3 May 2001, Wez Furlong wrote: On 2001-05-03 22:51:41, Wez Furlong [EMAIL PROTECTED] wrote: | John Donagher [EMAIL PROTECTED] Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. +1 It will work, right (zend guys?). I'd love to see it. I really don't see why you would want this (correct case of class names being returned). But besides that, its not (imho) worth the speed decrease (and kludge factor) to implement. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On 2001-05-03 22:53:49, Andrei Zmievski [EMAIL PROTECTED] wrote: On Thu, 03 May 2001, Wez Furlong wrote: OK, so +1 to get_declared_class() which returns the class name with Umm, that sounds kind of arbitrary. There could be an optional parameter to get_class(), get_parent_class(), and others that specifies which class name to return. You're right. * How would this sentence be different if Pi was equal to three? * * How would this sentence be different if Pi was not equal to three? * --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Hi Sterling- There are implementation-specific reasons of why this can be useful, but I was hoping to avoid the I can't see why you'd want this (very common on this list, and something I'm also guilty of, but limiting to the evolution of the language IMHO) argument in favor of semantically that's probably the right way to do it, but it's not real important, which is why I'm willing to make the change if the concensus is that the change would be the right thing. I definetly believe it's not real important and will have no visible benefit to most people. What I want to be sure of is that it won't hurt most people either. I'm not sure if the speed decrease would be noticeable. I don't get your argument about it being a kludge; I think what we have now is the kludge. I do agree a get_declared_class() would probably have a high WTF factor, which is why I favor changing the original to (like Andrei said) accept a parameter which determines its behavior. Thanks John On Thu, 3 May 2001, Sterling Hughes wrote: On Thu, 3 May 2001, Wez Furlong wrote: On 2001-05-03 22:51:41, Wez Furlong [EMAIL PROTECTED] wrote: | John Donagher [EMAIL PROTECTED] Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. +1 It will work, right (zend guys?). I'd love to see it. I really don't see why you would want this (correct case of class names being returned). But besides that, its not (imho) worth the speed decrease (and kludge factor) to implement. -Sterling -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 03:16 PM 5/3/2001 -0400, John Donagher wrote: Hi Sterling- There are implementation-specific reasons of why this can be useful, but I was hoping to avoid the I can't see why you'd want this (very common on this list, and something I'm also guilty of, but limiting to the evolution of the language IMHO) argument in favor of semantically that's probably the right way to do it, but it's not real important, which is why I'm willing to make the change if the concensus is that the change would be the right thing. I definetly believe it's not real important and will have no visible benefit to most people. What I want to be sure of is that it won't hurt most people either. I'm not sure if the speed decrease would be noticeable. I don't get your argument about it being a kludge; I think what we have now is the kludge. I do agree a get_declared_class() would probably have a high WTF factor, which is why I favor changing the original to (like Andrei said) accept a parameter which determines its behavior. I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I don't think any of these two options warrants a feature which maybe three PHP users will be dependent on. Talking about semantics, as the class name is defined as case insensitive it actually does make some kind of sense of declaring a consistent way the symbols will look after compilation, i.e., lower case letters. This is similar to how other case insensitive compilers work. If lots of people completely disagree with me then we can take a look at your patches and see if they make sense both on a complexity level and a performance level. I know this isn't the answer you want to hear but this code is fragile, the hash tables are used by just about any part in PHP and on a whole I just don't think it's worth it. It's not like a great feature everyone has been missing and semantically it's not obviously more right than the way it is today. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
On Thu, 3 May 2001, John Donagher wrote: Hi Sterling- There are implementation-specific reasons of why this can be useful, but I was hoping to avoid the I can't see why you'd want this (very common on this list, and something I'm also guilty of, but limiting to the evolution of the language IMHO) argument in favor of semantically that's probably the right way to do it, but it's not real important, which is why I'm willing to make the change if the concensus is that the change would be the right thing. I'm asking why do you want this? Because that's really what dictates changes more than anything. Its simple, if you can explain to enough people on this mailing list why you want the feature, and you can therefore convince enough of them they want the feature to be added, that's what will get the feature put in PHP. Currently, I see no real reason for it, perhaps you can give me one? As for semantics, I don't agree with your proposal. If you declare classes in PHP, they are case in-sensitive. Therefore, if you ask for the name of the class, its case really shouldn't matter either, having the classes always returned in lower case makes it easier because you always know the case the class will be returned in. I definetly believe it's not real important and will have no visible benefit to most people. What I want to be sure of is that it won't hurt most people either. I'm not sure if the speed decrease would be noticeable. I don't get your argument about it being a kludge; I think what we have now is the kludge. I do agree a get_declared_class() would probably have a high WTF factor, which is why I favor changing the original to (like Andrei said) accept a parameter which determines its behavior. We're describing two different things. I'm describing the implementation of the feature as a kludge (I can see no clean way), not the feature itself. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 02:38 AM 5/4/01 +0300, Andi Gutmans wrote: I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I may be missing something here, but why not simply add another field to zend_class_entry that keeps track of the user declared name? I think that's all the original poster was asking for.. -Andrei -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 06:46 PM 5/3/2001 -0500, Andrei Zmievski wrote: At 02:38 AM 5/4/01 +0300, Andi Gutmans wrote: I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I may be missing something here, but why not simply add another field to zend_class_entry that keeps track of the user declared name? I think that's all the original poster was asking for.. I still don't think this is something lots of PHP users will benefit from. On the contrary, I think semantically it is more correct to define what the case insensitivity means (names are converted to lower case). How many examples can you think of where this would actually help a PHP developer? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote: I still don't think this is something lots of PHP users will benefit from. On the contrary, I think semantically it is more correct to define what the case insensitivity means (names are converted to lower case). How many examples can you think of where this would actually help a PHP developer? Purely cosmetically, it would be nice. For example, in PHP-GTK I have a lot of error messages that output class names, and it'd be nice to display the names as they were registered by the user/system rather than all lowercased. -Andrei -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 06:54 PM 5/3/2001 -0500, Andrei Zmievski wrote: At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote: I still don't think this is something lots of PHP users will benefit from. On the contrary, I think semantically it is more correct to define what the case insensitivity means (names are converted to lower case). How many examples can you think of where this would actually help a PHP developer? Purely cosmetically, it would be nice. For example, in PHP-GTK I have a lot of error messages that output class names, and it'd be nice to display the names as they were registered by the user/system rather than all lowercased. In the constructor of your class you can save the class name to a variable if it's that important to you :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
At 03:12 AM 5/4/01 +0300, Andi Gutmans wrote: In the constructor of your class you can save the class name to a variable if it's that important to you :) sigh -Andrei -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
We use a Java-style methodology of naming classes as well as filenames, something we've adopted largely because of our use of PHPDoc. So, if you have a class FooBar, that class is defined in FooBar.cls, not foobar.cls. If get_class() returned the as-declared name, we'd have a really easy way to know where that class was defined. When you start getting into complex inheritance and class dependency trees, this issue finally rears its head. Other than this case, I have never cared. So, I've had to create a code generator to build a structure containing a mapping of class declaration names pointing back to filenames, which otherwise could not be accurately programatically determined. But if you use lowercased class naming, you can programatically determine the filename. That seems wrong to me. We (at my current company) have a clean architecture, something we're working on incorporating into a currently existing open-source application framework project to allow other people to use. So yes, three users may be affected by it now (maybe less :). I really don't want to propogate the kludge I've had to write out to hundreds of people, though. Don't change the code because of me, or because of the project I'm working on, or because of the way PHPDoc works. We've already worked around it. But I still maintain that tossing away the declared names is not the only (or the best) way to achieve case-insensitivity in the language. Believe me, I wouldn't have wasted cycles thinking/writing about this if I wasn't convinced it will benefit PHP and its users in the long run, even if the value add is relatively minor. On Thu, 3 May 2001, Andrei Zmievski wrote: At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote: I still don't think this is something lots of PHP users will benefit from. On the contrary, I think semantically it is more correct to define what the case insensitivity means (names are converted to lower case). How many examples can you think of where this would actually help a PHP developer? Purely cosmetically, it would be nice. For example, in PHP-GTK I have a lot of error messages that output class names, and it'd be nice to display the names as they were registered by the user/system rather than all lowercased. -Andrei -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]