On 15/01/15 07:26, Pavel Kouřil wrote: > And yesterday I was pointed out one thing: the RFC states "With this > approach, an argument is only accepted if its type is exactly the same > as the parameter.". Does this mean you cannot pass integer to a > function with float argument in the strict mode?
One of the nice features of PHP when I started using it all those years ago was that I did not have to create separate functions different types did exist in the source data. int/float/num/double and others all needed separate handling in c/c++, and one could not easily add a different 'type' of data. Nowadays I get around many of the problems that are currently all being debated by passing an 'id' or an array of data as the only parameter to a function. If the bigint 'id' is already loaded, the cached version is used, if not it is loaded or an empty default object created. If an array is passed then the relevant fields are actioned. With the current discussions I see what has become a style of working based on how PHP USED to work is now being pushed into the 'that is not the way to do it' box? I have named parameters, they are the elements of the array, order is not relevant, I can skip ones, or add new ones without affecting anything. I can see that for some nailing everything down and avoiding any flexibility is their target while others DO still subscribe to the lighter approach which allows in my book greater flexibility. So perhaps we are at a point where a big switch is needed much like e_strict to isolate the 'strict mode' from 'flexible mode'? I can see third party libraries having to provide different versions of the same code if this particular discussion goes down the wrong path? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
