While typing this I did think to just scrap what I was writing, but I think it is relevant if only if someone can explain why I am wrong?
On 19/02/15 17:06, Anthony Ferrara wrote: >>> With strictly typed $a and $b, the expression drops to 1 possible >>> >> permutation. And you can detect if it's a valid one. And many static >>> >> analysis engines do this. >> > I didn't see any proposal that proposes strictly types variables. As for >> > parameters, both strict and coercive typing provide knowledge about the >> > types of parameter inside the function they are defined in, so no >> > advantage to strict typing here. > It's not about how data gets in, it's about how data moves once it's > in. It's about knowing how types change and flow into other functions > that's important. Because that lets you determine more data about the > stable (non-error) state of the application. With much of this it is what validation needs doing where. Data coming into the process can either be well constrained, or totally random. Pulling stuff back from a database, it has already been sanitised and should be well constrained but even that may be questionable. Processing the data may well introduce other constraints and I make no apology hammering data size again. If we get an overflow for what ever reason it has to be handled, and while that may be by adding additional checks on a generic datatype, using a suitable already constrained type just seems logical. Even more so if your reason for introducing strict elements is to produce better optimized code? If all I need is a 16bit count and the process will never exceed that do I really want an unconstrained variable to represent it? I will put my hand up and say that up until now I've not worried about just how some of this works inside the box. It has only been since 64bit builds have become the norm and unexplained errors started that I have dug into that layer and to be honest some of the constraints that the zend objects have created perhaps does not make sense although it does explain why some people want to take it a stage further. If I have a variable which is populated by a string of characters as a starting point, then viewing that as a numeric value is a function of that object rather than creating a new different object. Back to my as_xxx rather than is_xxx ... as_xxx fails if the result can't be produced, or yes it gives a new object of that type. It's how all these extra objects exist that is confusing, but if all the persistent data simply creates objects of the correct type in the first place then why do you need to cast anything? -- 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
