Re: New Datetime class problem
| From: | Ilia Alshanetsky | Date: | Sun, 05 Nov 2006 18:44:38 +0000 |
| Subject: | Re: New Datetime class problem | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-26366@lists.php.net to get a copy of this message | ||
On 5-Nov-06, at 1:32 PM, Christian Schneider wrote:
Ilia Alshanetsky wrote:And your point is what? There are even more rules you need to obey while driving a car, when people forget those rules they often get into accidents. Same with programing, there are rules, you can choose to ignore them, but don't complain when your code is exploited because your didn't check your input or stopped working when an namespace you've been mis-using gets taken over by the language.There are no "rules" there is just one rule, that's not even specific to PHP when you think of it. It is generally considered to be a good practice to prefix your code with app name or similar to avoid conflicts with other libraries and/or applications. When it comes to this rule, I think it is one of the very few that are essential for developers to learn.What about "do not trust user input"? Or "avoid copy/pasting code, refactor instead"? Or "use descriptive identifiers"? Those are all rules to be followed when programming. And the more there are the more experience it takes to not get any of them wrong.
Actually it works with both date & time and calling it datedate seems rather silly. I am not going to waste more time arguing about DateTime, this has already been covered numerous time, if you got time to waste go read internals archives.Well, almost: DateTime is a date class, not a time class.This would mean classes should be prefixed by extension name...That is the common case, yes. In fact the date extension's classes follow this convention to the letter. DateTime + DateTimeZone (Date is the extension name).
That's your opinion and you are certainly entitled to it, but that's just it, your opinion. Ilia AlshanetskyHowever, for native classes there maybe exceptions to simplify usage, when a need for such exceptions arise this will be discussed on this list.We're only talking about native classes anyway. And I think not bending the rules simplify usage more than saving a couple of letters. Wasn't that a lesson we learned from functions?