Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26399
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <2F.C5.05668.5BD50554@pb1.pair.com>
To: internals@lists.php.net
References: <7f3ed2c30611031000j2dc48a6amb7f04c8011442b56@mail.gmail.com> <282B7D4B-DC15-4ABC-95A6-C03F766C19B7@prohost.org> <27664.208.195.234.246.1162844322.squirrel@www.l-i-e.com> <10845a340611070126hdd3cfe1v4f62a37d98f620e1@mail.gmail.com>
Date: Tue, 7 Nov 2006 11:19:30 +0100
Lines: 81
Subject: Re: [PHP-DEV] [PATCH] Scalar type hinting ;)
From: r.korving@xit.nl ("Ron Korving")

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"" <rquadling@googlemail.com> schreef in bericht 
news:10845a340611070126hdd3cfe1v4f62a37d98f620e1@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).
>
>
>
>
> -- 
> -----
> Richard Quadling
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> "Standing on the shoulders of some very clever giants!"