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]
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]
