On 18/09/15 18:11, Rowan Collins wrote: >> You don't want to disable expand() so the next step is handling the >> results of importing variables for which null is a valid state but >> equally their NOT having been created is equally valid. > > Sure, extract() allows you to do half the trick you want to do, and > exists() would allow you to do the other half. There's a logical jump > from there to "if you're not going to give me exists(), you might as > well take away extract()". > > It's like saying "I have some cheese, but no bread; if you gave me some > bread, I could make a cheese sandwich; if you're not going to give me > the bread, please take away the cheese". My answer amounts to "why don't > you have cheese and crackers instead, we've got plenty of those?"
All I am saying is that 'exists()' is simply part of the toolkit that goes WITH extract(). There is a suitable tool in arrays and in objects so why not complete the toolkit in straight variables. The names are a mess between the three for many reasons and producing a complete new set of function names has been another call, but there is a simple hole here in a style of coding which there seems little logical reason NOT to fill. Saying 'you don't need it if you change coding style' is simply the wrong answer for something where the rest of the toolkit is being retained. All I'm trying to explain is why it IS a hole in this style of coding. -- 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
