On 17/02/15 21:28, François Laupretre wrote: >> De : Lester Caine [mailto:les...@lsces.co.uk] >> >> On 17/02/15 18:33, François Laupretre wrote: >>> What does this mean in your case ? Just that, as long as the feature is not >> available, your function won't have an explicit return type. Period. And, >> please, don't change false to 0 ;). >> >> I simply can't see the case for limited function type hints at all! I > > If you can't see it after so much was written on the subject, what can we do > ? Do you imply that, if *you* cannot understand the need, it does not exist ?
Since it has already been said that what is proposed is 'just a start' then the missing bits may get added later - and if it is anything like PDO will it arrive before PHP10 :) >> either already have clean defined data from the database, or I need to >> validate the data from users before using it. > > If that's your only data source, that's OK. I confirm you probably don't need > type hinting. You probably even don't need functions, classes and the rest. A > 50-line script should fit. http://hg.lsces.org.uk/bw/bitweaver/ is a little more than 50 lines ... lsces.org.uk/bitweaverdocsPHP/index.html hasn't been updated since we lost the original phpDocumentor but now I do need to try and get a new version run including all the e_strict stuff that hs been reworked in the last 5 years. >> While validating I need to >> confirm constraints of data type so adding some extra wrapper that only >> does half the job just seems a pointless exercise. > > The point of type hinting is not validating user input. Again limited application of a useful function. Strict scalar type hints are only there to give an error when something is wrong. How is that not doing validation? If you HAVE validated the data then where do you need the hint other than reminding you just what you need to validate to? And if you have validated then one can pass a value rather than a string anyway? >> Annotating the >> correct data type would be of more use and I already have that in the >> docblock and my IDE produces those hints while I am writing the code - >> which it has done for many years. > > That's different. There is overlapping there but the purpose is not the same. > IDEs only can do a limited set of static analysis. As soon as you have > indirect calls, IDE-based static analysis is down, let alone comment-stripped > libraries and others. If you want more constraints on input and output, look > at DbC (design by contract), as it can handle tests too slow to run in > production. I would not even bother trying to understand the PHP code base without a decent IDE, and Eclipse provides that. PHP files live next to C/C++ and other file formats, so the one set of tools allow everything to work productively. I don't find any problem seeing indirect call annotation and although PHPeclipse is now struggling with new things ( like dropping the ?> in the MIDDLE of phpt files :( ) it has done the jobs that most of this extra infrastructure is trying to duplicate for a lot of the life of PHP5. > To my mind it IS in the IDE that much >> of this stuff which people keep saying is not 'runtime' should be >> managed, and anything that is not needed at 'runtime' should be >> removable but what is being added across several areas all seem to >> beadding the same things - partially - using different methods - without >> any obvious gain. Additionally I'm now passing data as an array as that >> was the 'best practice' a few years back so it is rare to be passing a >> single value anyway. > > IDEs are worthwile but not mandatory and runtime features have nothing to do > with IDEs. > Now, you were (aggressively) complaining about returning int or false. You > were sure you had found the case that would prove all of this was ready for > the bin. I took the time to explain. Then, you're complaining it's no use > because you don't understand its purpose and because you chose to bundle your > arguments in arrays... Flagging that a value HAS to be an integer is fine, and hopefully the move to make that an unconstrained object rather than a simple register value has passed, but even here the next step is rather than hiding the fact that in many cases there IS a limit, the move to 64bit values in parallel with 32bit ones needs much better management and it's the total disregard for that which is my problem. 'PHP has not worried about that in the past' neatly sidesteps the fact that we USED 32bit builds of PHP5 to avoid the problems, but nowadays we have legacy systems that are still locked to 32bit values while new systems are running 64bit and so now it IS something to at least take some interest in. int4 and int8 are equally as important as int(unlimited) and while ignoring 32bit builds may be practical for some, it still has a place in many areas. > Unfortunately, I'm afraid I can't do more for you but what I generally hate : > 'If we don't like it, don't use it'. > > I try to be kind with constructive posts but, here, I have better to do. I've indicated where I would have less of a problem with 'hinting' if it was actually providing a complete set of hints. Being able to apply those hints to the elements of an array would be useful, but this is where 'other camps' would be expecting data to be returned as objects with all the overheads that applies but which the current offerings probably fit better with? Validation of data IS the problem here but this is not a solution to that problem, just another sticking plaster. -- 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
