Making E_STRICT stricter
Anyone who hangs around the #phpc room on freenode, know how much I enjoy complaining about PHP annoyances. The fact of the matter is that because of PHP’s irregularities unless you have intimate knowledge of how a function works, it’s VERY difficult to predict its behavior.
explode('\n', $string);
strtok($string, '\n');
Explode and strtok, are simple examples about parameter ordering discrepancies. The fact that strchr() is an alias of strpos(), but strrchr() doesn’t work like strrpos(), is another example. There are a lot more. These things must be addressed before PHP is ready for the enterprise.
There is a way. My suggestion would be to create a new set of functions which have standardized naming and parameter ordering. The existing functions will still work (there will be no BC breaks), but will throw an E_STRICT warning. Something like this would have been nice to get into a major release (like PHP5), but it could still be pulled off.
The final step takes place in a future Major PHP release which is released in X years and is fully E_STRICT compatible. And we will be forever rid of is_writeable() and it’s ugly friends.
September 20th, 2004 at 12:58 pm
It would be good if someone actaully took the time to do it, but that doesn’t sound like something that will happen any time soon. Personally though, I’d rather have e.g. the string data type replaced with a string object that would have all (most) of the current global string functions as member functions. There would of course still be a lot of global functions that it could be applied to.
Standard naming has already been applied in some places (e.g. in the pgsql module), keeping the old function names working and just not listing them in the manual (except in a table listing the changes). The E_STRICT warning would be a nice addition though.
September 20th, 2004 at 1:56 pm
Yeh, that would be nice, but it would be breaking too much. I’m not really talking about adding any new features. I’m just talking about standardizing what we already have.
I can see that there is some format of standard naming going on, but if it’s not applied across the board then it’s useless.
Coogle mentioned that this was an old idea… and nobody could be bothered with implementing it. I agree that up till now PHP development has just been “scratching an itch” style development, and this type of major cleanup is not nessesary. Since PHP5 we’ve seen all kinds of “PHP Grows up”, “PHP Ready for the Enterprise” hype going on. Maybe one of the commercial PHP companies would sponser the implementation of something like this.
September 21st, 2004 at 12:32 pm
That’s a point that really bugs me everytime in PHP. Even as experienced developer you have to look often in the manual to determine what parameter order is wanted and things like that. If that would be standarized, the developement speed will raise and PHP would have a great benefit from it. Hope that someone will take this task
(I would, but I’m not good in C(++), still learning)
September 30th, 2004 at 11:13 pm
I agree this is a good thing to strive for. Rather than trying to convince pear-dev to do this internally, couldn’t such standards be implemented with PEAR wrappers? Not ideal but ‘if the people lead’ maybe the leaders will follow…someday
January 23rd, 2005 at 8:11 pm
I agree about the annoyances, totally. I strongly disagree with one of the replies:
“Personally though, I’d rather have e.g. the string data type replaced with a string object that would have all (most) of the current global string functions as member functions.”
I have got really really sick of hearing this suggestion. It is purely evil and insidious, and should be stamped on wherever it is found.
PHP is not Python. It is not Java. It is not Javascript. If you want people forced to use your sick OOP, the please foad or use one of those other sick languages. Do NOT to this to PHP.
OOP is now (and hopefully always will be) an optional feature of PHP, which can be competely avoided should you so desire.
This is a strong feature of PHP.
Keep it that way.