18 messages in net.php.lists.internalsRe: [PHP-DEV] [PATCH] Scalar type hin...
FromSent OnAttachments
Hannes MagnussonNov 3, 2006 10:00 am.txt
PierreNov 3, 2006 10:39 am 
Marcus BoergerNov 3, 2006 10:46 am 
Ron KorvingNov 3, 2006 10:48 am 
Ilia AlshanetskyNov 3, 2006 11:06 am 
PierreNov 3, 2006 11:12 am 
Zeev SuraskiNov 3, 2006 12:34 pm 
Brian MoonNov 3, 2006 2:45 pm 
Richard LynchNov 6, 2006 12:18 pm 
Markus FischerNov 6, 2006 11:00 pm 
Richard QuadlingNov 7, 2006 1:26 am 
Ron KorvingNov 7, 2006 2:19 am 
Richard QuadlingNov 7, 2006 2:39 am 
Christian SchneiderNov 7, 2006 6:45 am 
Richard QuadlingNov 7, 2006 7:33 am 
Richard LynchNov 7, 2006 10:45 am 
Richard QuadlingNov 8, 2006 1:37 am 
Derick RethansNov 15, 2006 12:19 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [PHP-DEV] [PATCH] Scalar type hinting ;)Actions...
From:Richard Quadling (rqua@googlemail.com)
Date:Nov 7, 2006 2:39:09 am
List:net.php.lists.internals

On 07/11/06, Ron Korving <r.ko@xit.nl> 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"" <rqua@googlemail.com> schreef in bericht news:1084@mail.gmail.com...

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).