> On 24/07/12 19:32, Alex Aulbach wrote: >> >> 2012/7/24 Andrew Faulds <a...@ajf.me>: >>> >>> But PHP functions usually have side-effects, they aren't strict >>> mathematical >>> functions. >> >> Ah, you might mean str_tok()? Are there more, do you have a list? >> >> But we're in PHP-programming-context. You write a function in PHP, you >> call it and it will return once called. I see there no exeption. >> >>> So complaining about this is rather pointless. >> >> I don't complain about the past. I just think now, that if it doesn't >> behave like a function it shouldn't be called function. A function >> which returns as an object and is not completed is not a function. >> >> And if other languages do so, my argument will be the same. >> >> <rising finger with epic mimic, fistulous voice> We need not to make >> the same mistake again! :) >> > All the array_* functions have side effects. Most class methods, which are > also functions, have side effects. Most of the functions I write have side > effects. Much of mysql_* has side effects. > > PHP is not LISP. >
LISP has side effects. > > -- > Andrew Faulds > http://ajf.me/ > > > -- Trying to solve cultural problems with the programming language rarely works. I don't think it contributes much to how well a developer will learn the use of generators with whether we use function or another keyword. With that said I believe that's the point of a discussion phase and I'd like to offer that we're free to implement it how we want. PHP made implementation mistakes in the past that led to awkward behavior (like objects passed by value in PHP4), but that's never stopped things from moving forward and offering up useful features that users want. I think putting the technical details aside the engine can aid a developer in distinguishing between spotting unintended side effects and preventing disastrous consequences. You have similar issues with developers that try to execute database queries while there are buffered results or developers that inadvertently write infinite loops. There are enough safeguards in place to help avoid such nuances. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
