I wouldn't like E_NOTICE. I agree that the result should be a NULL value if a conversion fails, but E_NOTICE shouldn't be mixed in the area of user data. All error reporting should be limited to code, not input. I don't want the users of my software to be able to trigger E_NOTICE (or any error for that matter). I write code that ensures that no error/warning/notice will ever be triggered no matter what a user does.
I don't see a point in a hint called "mixed" either. You might as well not use a hint for that particular function parameter. Just my 2 cents. Regards, Ron Korving ""Richard Quadling"" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > Not in direct reply to any message. > > Type hinting is on for classes and arrays (maybe resources too - not > sure - but certainly a good idea if not). Why? From my perspective, it > allows me to not deal with potential errors either in the data or my > coding or another developers coding. > > Type hinting is part of the documentation. Sure, hungarian notation of > variable names (where the type is represented within the variable name > itself) is a good start, but when you get to things like a 4d array of > string and integer pairs, you get more notation than variable name. > > Extending type hinting to scalars is the next step. The loose typing > of PHP is great, but as mentioned by Richard Lynch, we have to more or > less move away from it for user input and DB input. > > Even when we store data in the session it is stored in type, so, > pretty much after getting the source data to operate on, the type is > fixed. > > You don't store a number in the session and get it back as a string to > convert back to a number in the next session usage. You store a > number, you get a number back. > > So, where is the use for loose type? You can't loose type objects or > arrays or resource. You no longer need to loose type user input or DB > input (cause you are now using SOME sort of input filtering > mechanism). > > > An issue is very much where you have mixed types (which many of the > PHP functions support). How do you hint this? You could either used > mixed or blank, but maybe you can supply multiple types which the > function will support. > > Maybe for V6 type hinting for scalars could be available, but output > purely E_NOTICE. Really make them just a hint. A suggestion. This will > allow auto documentors get to grips with things, allow code complete > editors deal with user defined functions, etc. > > Sometime after that the facility to make the hints become enforcers. > There would be a published list of conversion mechanisms (the > equivalent PHP function in effect). You could potentially allow user > defined conversions for user defined types though I would see this as > a WIBNI, rather than a MH. > > If you don't have any hints then nothing changes. If you do have > hints, then you would have to accept the hit in the additional > checking. If you have the enforcement, then you would have to deal > with the NULLs that would result in failed conversions (I would > recommend NULL rather than any other value for failed conversions). > > > > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
