On 07/11/06, Ron Korving <[EMAIL PROTECTED]> wrote:
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.
If you are using filtering, then the user input will be clean. The use of the E_NOTICE (in the true "hint" mode) would be valid. You expected to supply an int, but you supplied something else AFTER the filtering. This notice would be seen at dev time and you'd realise that either you used the wrong hint or the filterting was wrong. If you do not filter the user data, then the hints ARE going to be wrong in the main as the user data is all strings (unless you use string as the hint all the time ...) Hinting goes hand-in-hand with filtering.
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.
Hmm. I see your point here and I sort of agree here. Another WIBNI if it could be implemented easily enough.
Just my 2 cents. Regards, Ron Korving
If this goes ahead, then I would see this IS a radical change to PHP. It is going from the free-for-all of loosely typed code to a developer centric strong typed language. But the cool aspect is that you do NOT have to use hints. No hints, nothing changes. THIS is why type hinting and type enforcing should be added. For those that want it, you can have it! For those that don't know or care, nothing changes. Having come from C/Delphi/Sage Retrieve 4GL, it makes sense to me to have hints. I suspect if I had been exposed to another loosely typed language first, then I wouldn't care.
""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
-- ----- 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
