[PATCH] Scalar type hinting ;)

php.internals

Hannes Magnusson

19 years ago
Hello all! Attached is a patch (against 5_2) to allow scalar type hinting \o/ I realize that maaany will be against it so I won't be pushing it (a lot), just wanted the patch archived somewhere :) A .tar.bz2 archive can be found at http://home.oslo.nith.no/~maghan/scalar.type.hint.tar.bz2 containing the patch, phpt fixes and new phpt tests. -Hannes (maybe I should had said "if there are no objections I'll commit this by the end of next week" hoping everyone were busy and wouldn't notice this mail *evil wink*)

Pierre Joye

19 years ago
Hello, On 11/3/06, Hannes Magnusson <hannes.magnusson@gmail.com> wrote:
> Hello all! > > Attached is a patch (against 5_2) to allow scalar type hinting \o/ > > I realize that maaany will be against it so I won't be pushing it (a > lot), just wanted the patch archived somewhere :)
-1 unless we add a "strongly typed" mode in php and allow scalar type hinting only in this mode. But thinking about php raising errors when I pass string("1") instead of int(1 )is not really what I consisder as a nice addition :) --Pierre

Marcus Börger

19 years ago
Hello Pierre, i think it would only make sense if the automatic type conversion is correctly supported but then why use it at all? That by the way is the reason we declined it in the past several times. best regards marcus Friday, November 3, 2006, 7:39:41 PM, you wrote:
> Hello,
> On 11/3/06, Hannes Magnusson <hannes.magnusson@gmail.com> wrote: >> Hello all! >> >> Attached is a patch (against 5_2) to allow scalar type hinting \o/ >> >> I realize that maaany will be against it so I won't be pushing it (a >> lot), just wanted the patch archived somewhere :)
> -1 unless we add a "strongly typed" mode in php and allow scalar type > hinting only in this mode. But thinking about php raising errors when > I pass string("1") instead of int(1 )is not really what I consisder as > a nice addition :)
> --Pierre
Best regards, Marcus

Pierre Joye

19 years ago
Hello, On 11/3/06, Marcus Boerger <helly@php.net> wrote:
> Hello Pierre, > > i think it would only make sense if the automatic type conversion is > correctly supported but then why use it at all? That by the way is the > reason we declined it in the past several times.
Exactly --Pierre

Zeev Suraski

19 years ago
At 11:12 03/11/2006, Pierre wrote:
>Hello, > >On 11/3/06, Marcus Boerger <helly@php.net> wrote: >>Hello Pierre, >> >> i think it would only make sense if the automatic type conversion is >>correctly supported but then why use it at all? That by the way is the >>reason we declined it in the past several times. > >Exactly
Exactly++. And it doesn't make sense to have different semantics for the same type-hinting feature (ensuring the right type, or converting to the right type), therefore, no scalar type hinting. Zeev

Ron Korving

19 years ago
If you ask me, scaler type hinting should try to do some auto-conversion. That way, the type hints would actually be useful. -- Ron PS: Congrats on rolling out PHP 5.2.0. I sincerely (without sarcasm) hope the manual will be updated soon (e.g. filter extension is still marked experimental and datetime classes have not been documented at all). "Pierre" <pierre.php@gmail.com> wrote in message news:fe05d1540611031039qee11e7aicfe71868aa5d0588@mail.gmail.com...

Brian Moon

19 years ago
Ron Korving wrote:
> If you ask me, scaler type hinting should try to do some auto-conversion. > That way, the type hints would actually be useful.
While I like the idea of type hinting on scalars, I agree that it causes issues. Using request data is the main issue. Its all strings. The only way I see it working is if the hints converted the data and checked if it "changed". So, "1" and 1 are "the same" so it does not complain. Likewise, any number could be changed to a string. But non-numeric strings changing to 0 would throw an error. That is the main place where scalars cause issues. That does bring up the question of why scalar as a hint is not supported. function test (scalar $var) { echo $var; } I would seem that would have made sense. Currently, that code throws: Fatal error: Argument 1 passed to test() must be an object of class scalar That is funny on its own.
-- Brian Moon ------------- http://dealnews.com/ It's good to be cheap =)

Ilia A.

19 years ago
Hannes, As much as I like the concept I would prefer to hold it off until the next minor release or PHP6. On 3-Nov-06, at 1:00 PM, Hannes Magnusson wrote:
> Hello all! > > Attached is a patch (against 5_2) to allow scalar type hinting \o/ > > I realize that maaany will be against it so I won't be pushing it (a > lot), just wanted the patch archived somewhere :) > > A .tar.bz2 archive can be found at > http://home.oslo.nith.no/~maghan/scalar.type.hint.tar.bz2 containing > the patch, phpt fixes and new phpt tests. > > -Hannes > (maybe I should had said "if there are no objections I'll commit this > by the end of next week" hoping everyone were busy and wouldn't notice > this mail *evil wink*) > <scalar_type_hint.patch.txt> > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky

Richard Lynch

19 years ago
On Fri, November 3, 2006 1:06 pm, Ilia Alshanetsky wrote:
> As much as I like the concept I would prefer to hold it off until the > next minor release or PHP6.
I can actually see a fair amount of merit in having a "strict" mode with type hints raising this kind of error... If you're prototyping something you intended to port to C, but wanted the freedom in prototyping phase to play fast and loose with types, but then wanted to transition to a "strict" mode in PHP before you went whole-hog into C. Or, for some applications, in some modules, I think it would make sense to be able to declare a particular function as NOT accepting the usual rules of type-juggling. Or, in my own little theoretical world, perhaps, to allow only a certain acceptance level of type-juggling, such as "1" -> 1 is okay, but "1 banana" -> 1 is not okay. Not that I'm under any illusion that THAT level of type-hinting will pass muster... :-) But, to some degree, the whole filtering extension is all about this same Principle of what is or isn't acceptable input, focussed mostly on user input. Perhaps the filter extension can be employed at the function level, somehow, to say that such and such a function will only accept a true (int) or something that passes filter XYZ. It's not something that should be on by default, but it's not a completely merit-less feature to desire, by any means. How to do it efficiently, as an extra option, in a meaningful way is the issue. I'm pretty sure the patch supplied isn't really going to be a viable answer across the board, but it's a good place to start a discussion of "What if..." As I thought about this more, it seems like the type-juggling is really super incredibly useful in two main situations for me: Input data from HTTP, which is always text. Data from the DB interfaces, which doesn't always come out in a nice native form. E.g. PostgreSQL booleans end up as 't' and 'f' string :-( But if the new input filters auto-convert to the desired required output data type, and if the DB functions were a bit more type-aware, I'd actually LIKE the data-types to do an E_NOTICE if they were type-juggling almost anything else. I never want to type '1' in source and have it turn into 1 later on. I *love* that PHP doesn't make my write a bunch of code to convert all the HTTP text into meaningful data, mind you. But if I have to do all this filtering stuff anyway, because of all the [bleeps] out there, I'm losing on that front anyway. Fix up the DB calls to return the right data-types across the board, and I'm really left with no strong desire for automatic type-juggling. Which sounds really weird to say, given how useful it's been to me the past decade, but that's where I am today. Not that I plan to run off and try some other language or anything, so I guess I'm not feeling THAT strongly about this. :-)
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Richard Quadling

19 years ago
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!"

Ron Korving

19 years ago
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...

Richard Quadling

19 years ago
On 07/11/06, Ron Korving <r.korving@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"" <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!" > > -- > 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!"

Richard Lynch

19 years ago
On Tue, November 7, 2006 4:19 am, Ron Korving wrote:
> I wouldn't like E_NOTICE. I agree that the result should be a NULL > value if > a conversion fails,
Assume, for the sake of argument, that someday one's type-hint could be: function foo ([NULL | int] $bar){ } Also assume the paramter passed to $bar is '42' Then is converting to NULL really the right answer?... I don't have a BETTER answer, mind you... Seems to me, though, that if you're willing to turn on type-hinting, and you restrict your function to accept only [NULL | int], then I'd be more happy with PHP throwing something bigger than E_NOTICE and converting the input to NULL and carrying on... Seems to me, that once you commit to the type-hinting, a failed conversion oughta be E_ERROR...
> 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.
You may need [mixed] if the PHP Manual under-documents what return values occur in the case of errors (which is the current state-of-the-art, really) and you don't know for sure what is going to come back, but you want something there, just so you know it's "not right yet"
>> 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.
WIBNI? MH? [shrug] I get the gist from context, but may be missing details... :-)
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Richard Quadling

19 years ago
My suggestion was to introduce type hinting gradually. First of all type hints, would be just that, hints. A suggestion as to the recommended type. If hints are used and the types do not agree, then this is an E_NOTICE. If you are using hints then you are expecting the types to be right. If you don't use hints, then nothing extra. The notice would be present simply because it is an advisary notice. Nothing is enforced. No type conversion would take place, but it would mean you could see which methods/functions are getting values which may need converting. Maybe this could be E_STRICT. By using hints, you are implying strict coding. I could go with that. The next stage could be to allow automatic conversion based upon the normal type juggling rules OR to use a type conversion table which would use the same PHP functions that would be used in userland to do the conversion manually. In some cases this is just casting, but in other cases the conversion of 'december' to a number (for example) should result in NULL. I do agree (having re-read my own post) that a failed conversion is an E_ERROR (or E_STRICT again). Again, if you are using type hinting and are using automatic conversion, you have to obey the rules. It may be that you could supply your own conversion rules. A potentially useful feature would be to allow for a user defined automatic type conversion table. So, a user could effectively wrap the parameters to their own type and use their own type conversion logic. This does allow for the creation of user defined types (which I suppose are classes ... ) The final stage would be to apply a strict mode and that type hinting is actually type enforcement. If a function or a method says it ways an int, it must have an int. If not, then then this is a fatal error. No automatic conversion. If this is combined with filtering, I think you should actually have a fewer type conversions. You get the data as a string from a user form. You know that the 3 columns representing a DOB are actually numeric. You use a filter to force them to numeric types. From that point on, why do you need to know that they are strings? You pass the values around as integers. If you pass them to a mktimt() function, they are in the correct type already. This SHOULD mean less type conversions. WIBNI - a very old acronym for Wouldn't It Be Nice If. MH - the opposite to a WIBNI, a Must Have. The introduction of type hints for scalars is under discussion. I'm strongly in favour of them. It may be that I don't need them once I start using the standard input filtering (I use my a mechanism described by Marco Tabini in php|Architect - Poka-Yoke). I think this comes down to a set of choices. You can do everything yourself. No hints, no automatic filtering, etc. You can restrict what you want to do. Using enforced typing, using automatic filtering, etc. I've come from an environment where each method/function is defined by the interface and the types. If I supply the wrong type the code wouldn't compile or worse. If PHP uses type hinting/enforcement, then for all the CURRENT PHP code out there, nothing would change. Of course all of this can be avoided if you didn't use scalars but had all variables as objects (Eek! It would work - I think - but eek). On 07/11/06, Richard Lynch <ceo@l-i-e.com> wrote:
> On Tue, November 7, 2006 4:19 am, Ron Korving wrote: > > I wouldn't like E_NOTICE. I agree that the result should be a NULL > > value if > > a conversion fails, > > Assume, for the sake of argument, that someday one's type-hint could be: > > function foo ([NULL | int] $bar){ > } > > Also assume the paramter passed to $bar is '42' > > Then is converting to NULL really the right answer?... > > I don't have a BETTER answer, mind you... > > Seems to me, though, that if you're willing to turn on type-hinting, > and you restrict your function to accept only [NULL | int], then I'd > be more happy with PHP throwing something bigger than E_NOTICE and > converting the input to NULL and carrying on... > > Seems to me, that once you commit to the type-hinting, a failed > conversion oughta be E_ERROR... > > > 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. > > You may need [mixed] if the PHP Manual under-documents what return > values occur in the case of errors (which is the current > state-of-the-art, really) and you don't know for sure what is going to > come back, but you want something there, just so you know it's "not > right yet" > > >> 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. > > WIBNI? > MH? > [shrug] > > I get the gist from context, but may be missing details... :-) > > -- > Some people have a "gift" link here. > Know what I want? > I want you to buy a CD from some starving artist. > http://cdbaby.com/browse/from/lynch > Yeah, I get a buck. So? > > -- > 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!"

Christian Schneider

19 years ago
ini_set('humour', "On"); Richard Quadling wrote:
> 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
I wouldn't have expected anyone to use hungarian notation with PHP. But then again that's what the Spanish inquisition would probably use to torture nowadays and who expects the Spanish inquisition? (-:C On the other hand it is easy to do it in PHP: Just prefix every variable with "m" :-)
> 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.
Error: Incompatible use of constant 'we'
> 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
ini_set('humour', "Off"); All type hints warnings should be E_STRICT, not E_NOTICE IMHO. If that's the case then you can add as many bondage feature as you wish as long as they don't slow down non-strict code ;-) - Chris

Richard Quadling

19 years ago
On 07/11/06, Christian Schneider <cschneid@cschneid.com> wrote:
> Error: Incompatible use of constant 'we'
"us" didn't make any sense! Maybe y'all, or everyone would have been better. <grin />
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Derick Rethans

19 years ago
On Fri, 3 Nov 2006, Ilia Alshanetsky wrote:
> Hannes, > > As much as I like the concept I would prefer to hold it off until the next > minor release or PHP6.
Yeah, same here. I would like to see this as well in PHP 6. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Markus Fischer

19 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Although my vote probably doesn't count, I'm strongly for it. I understand Pierre's and Zeevs arguments, but I think the fact that this is all optional ("you don't have to use it, if you don't want it") makes less a problem of this. And I really can see the benefits for large frameworks, like our company internal ones or let's name it, even Zend Framework and all the others out there. Of course this widens the gap between the probably more then usual "php scripter" and the "real php developer", but then I would say, be it that way. It can make things from a software architectural view so much easier (more type hinting, less unexpected behaviors deep inside applications). After all the patch also doesn't look very intrusive. - - Markus Hannes Magnusson wrote:
> Hello all! > > Attached is a patch (against 5_2) to allow scalar type hinting \o/ > > I realize that maaany will be against it so I won't be pushing it (a > lot), just wanted the patch archived somewhere :) > > A .tar.bz2 archive can be found at > http://home.oslo.nith.no/~maghan/scalar.type.hint.tar.bz2 containing > the patch, phpt fixes and new phpt tests. > > -Hannes > (maybe I should had said "if there are no objections I'll commit this > by the end of next week" hoping everyone were busy and wouldn't notice > this mail *evil wink*) > > > ------------------------------------------------------------------------ > > Index: Zend/zend_API.h > =================================================================== > RCS file: /repository/ZendEngine2/zend_API.h,v > retrieving revision 1.207.2.8.2.5 > diff -u -r1.207.2.8.2.5 zend_API.h > --- Zend/zend_API.h 18 Jul 2006 09:06:32 -0000 1.207.2.8.2.5 > +++ Zend/zend_API.h 3 Nov 2006 13:28:51 -0000 > @@ -62,8 +62,8 @@ > > #define ZEND_ARG_INFO(pass_by_ref, name) { #name, sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref, 0, 0 }, > #define ZEND_ARG_PASS_INFO(pass_by_ref) { NULL, 0, NULL, 0, 0, 0, pass_by_ref, 0, 0 }, > -#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name, sizeof(#name)-1, #classname, sizeof(#classname)-1, 0, allow_null, pass_by_ref, 0, 0 }, > -#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 }, > +#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT, allow_null, pass_by_ref, 0, 0 }, > +#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, IS_ARRAY, allow_null, pass_by_ref, 0, 0 }, > #define ZEND_BEGIN_ARG_INFO_EX(name, pass_rest_by_reference, return_reference, required_num_args) \ > zend_arg_info name[] = { \ > { NULL, 0, NULL, 0, 0, 0, pass_rest_by_reference, return_reference, required_num_args }, > Index: Zend/zend_compile.c > =================================================================== > RCS file: /repository/ZendEngine2/zend_compile.c,v > retrieving revision 1.647.2.27.2.20 > diff -u -r1.647.2.27.2.20 zend_compile.c > --- Zend/zend_compile.c 20 Oct 2006 02:44:02 -0000 1.647.2.27.2.20 > +++ Zend/zend_compile.c 3 Nov 2006 13:28:51 -0000 > @@ -1278,13 +1278,18 @@ > cur_arg_info = &CG(active_op_array)->arg_info[CG(active_op_array)->num_args-1]; > cur_arg_info->name = estrndup(varname->u.constant.value.str.val, varname->u.constant.value.str.len); > cur_arg_info->name_len = varname->u.constant.value.str.len; > - cur_arg_info->array_type_hint = 0; > + cur_arg_info->class_name = NULL; > + cur_arg_info->class_name_len = 0; > + cur_arg_info->type_hint = 0; > cur_arg_info->allow_null = 1; > cur_arg_info->pass_by_reference = pass_by_reference; > > if (class_type->op_type != IS_UNUSED) { > cur_arg_info->allow_null = 0; > - if (class_type->u.constant.type == IS_STRING) { > + cur_arg_info->type_hint = class_type->u.constant.type; > + > + switch (class_type->u.constant.type) { > + case IS_OBJECT: > cur_arg_info->class_name = class_type->u.constant.value.str.val; > cur_arg_info->class_name_len = class_type->u.constant.value.str.len; > if (op == ZEND_RECV_INIT) { > @@ -1294,10 +1299,9 @@ > zend_error(E_COMPILE_ERROR, "Default value for parameters with a class type hint can only be NULL"); > } > } > - } else { > - cur_arg_info->array_type_hint = 1; > - cur_arg_info->class_name = NULL; > - cur_arg_info->class_name_len = 0; > + break; > + > + case IS_ARRAY: > if (op == ZEND_RECV_INIT) { > if (Z_TYPE(initialization->u.constant) == IS_NULL || (Z_TYPE(initialization->u.constant) == IS_CONSTANT && !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) { > cur_arg_info->allow_null = 1; > @@ -1305,11 +1309,23 @@ > zend_error(E_COMPILE_ERROR, "Default value for parameters with array type hint can only be an array or NULL"); > } > } > + break; > + > + /* scalar type hinting */ > + case IS_BOOL: > + case IS_STRING: > + case IS_LONG: > + case IS_DOUBLE: > + if (op == ZEND_RECV_INIT && Z_TYPE(initialization->u.constant) != class_type->u.constant.type) { > + zend_error(E_COMPILE_ERROR, "Default value for parameters with %s type hint can only be %s", zend_get_type_by_const(class_type->u.constant.type), zend_get_type_by_const(class_type->u.constant.type)); > + } > + break; > + > + default: > + zend_error(E_COMPILE_ERROR, "Unkown type hint"); > } > - } else { > - cur_arg_info->class_name = NULL; > - cur_arg_info->class_name_len = 0; > } > + > opline->result.u.EA.type |= EXT_TYPE_UNUSED; > } > > @@ -1950,8 +1966,8 @@ > && strcmp(fe->common.arg_info[i].class_name, proto->common.arg_info[i].class_name)!=0) { > return 0; > } > - if (fe->common.arg_info[i].array_type_hint != proto->common.arg_info[i].array_type_hint) { > - /* Only one has an array type hint and the other one doesn't */ > + if (fe->common.arg_info[i].type_hint != proto->common.arg_info[i].type_hint) { > + /* Incompatible type hint */ > return 0; > } > if (fe->common.arg_info[i].pass_by_reference != proto->common.arg_info[i].pass_by_reference) { > Index: Zend/zend_compile.h > =================================================================== > RCS file: /repository/ZendEngine2/zend_compile.h,v > retrieving revision 1.316.2.8.2.7 > diff -u -r1.316.2.8.2.7 zend_compile.h > --- Zend/zend_compile.h 26 Sep 2006 10:30:50 -0000 1.316.2.8.2.7 > +++ Zend/zend_compile.h 3 Nov 2006 13:28:51 -0000 > @@ -159,7 +159,7 @@ > zend_uint name_len; > char *class_name; > zend_uint class_name_len; > - zend_bool array_type_hint; > + zend_uint type_hint; > zend_bool allow_null; > zend_bool pass_by_reference; > zend_bool return_reference; > Index: Zend/zend_execute.c > =================================================================== > RCS file: /repository/ZendEngine2/zend_execute.c,v > retrieving revision 1.716.2.12.2.12 > diff -u -r1.716.2.12.2.12 zend_execute.c > --- Zend/zend_execute.c 2 Oct 2006 11:09:52 -0000 1.716.2.12.2.12 > +++ Zend/zend_execute.c 3 Nov 2006 13:28:52 -0000 > @@ -513,12 +513,12 @@ > need_msg = zend_verify_arg_class_kind(cur_arg_info, &class_name, &ce TSRMLS_CC); > return zend_verify_arg_error(zf, arg_num, cur_arg_info, need_msg, class_name, zend_zval_type_name(arg), "" TSRMLS_CC); > } > - } else if (cur_arg_info->array_type_hint) { > + } else if (cur_arg_info->type_hint) { > if (!arg) { > - return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be an array", "", "none", "" TSRMLS_CC); > + return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be ", zend_get_type_by_const(cur_arg_info->type_hint), "none", "" TSRMLS_CC); > } > - if (Z_TYPE_P(arg) != IS_ARRAY && (Z_TYPE_P(arg) != IS_NULL || !cur_arg_info->allow_null)) { > - return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be an array", "", zend_zval_type_name(arg), "" TSRMLS_CC); > + if (Z_TYPE_P(arg) != cur_arg_info->type_hint && (Z_TYPE_P(arg) != IS_NULL || !cur_arg_info->allow_null)) { > + return zend_verify_arg_error(zf, arg_num, cur_arg_info, "be ", zend_get_type_by_const(cur_arg_info->type_hint), "", zend_zval_type_name(arg) TSRMLS_CC); > } > } > return 1; > Index: Zend/zend_language_parser.y > =================================================================== > RCS file: /repository/ZendEngine2/zend_language_parser.y,v > retrieving revision 1.160.2.4.2.1 > diff -u -r1.160.2.4.2.1 zend_language_parser.y > --- Zend/zend_language_parser.y 11 May 2006 21:07:39 -0000 1.160.2.4.2.1 > +++ Zend/zend_language_parser.y 3 Nov 2006 13:28:52 -0000 > @@ -129,6 +129,10 @@ > %token T_DOUBLE_ARROW > %token T_LIST > %token T_ARRAY > +%token T_BOOL_HINT > +%token T_STRING_HINT > +%token T_INT_HINT > +%token T_DOUBLE_HINT > %token T_CLASS_C > %token T_METHOD_C > %token T_FUNC_C > @@ -438,8 +442,12 @@ > > optional_class_type: > /* empty */ { $$.op_type = IS_UNUSED; } > - | T_STRING { $$ = $1; } > - | T_ARRAY { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_NULL;} > + | T_ARRAY { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_ARRAY;} > + | T_BOOL_HINT { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_BOOL;} > + | T_STRING_HINT { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_STRING;} > + | T_INT_HINT { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_LONG;} > + | T_DOUBLE_HINT { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_DOUBLE;} > + | T_STRING { $$.op_type = IS_CONST; Z_TYPE($$.u.constant)=IS_OBJECT;} > ; > > > Index: Zend/zend_language_scanner.l > =================================================================== > RCS file: /repository/ZendEngine2/zend_language_scanner.l,v > retrieving revision 1.131.2.11 > diff -u -r1.131.2.11 zend_language_scanner.l > --- Zend/zend_language_scanner.l 13 Apr 2006 13:48:28 -0000 1.131.2.11 > +++ Zend/zend_language_scanner.l 3 Nov 2006 13:28:52 -0000 > @@ -1079,6 +1079,22 @@ > return T_ARRAY; > } > > +<ST_IN_SCRIPTING>("bool"|"boolean") { > + return T_BOOL_HINT; > +} > + > +<ST_IN_SCRIPTING>"string" { > + return T_STRING_HINT; > +} > + > +<ST_IN_SCRIPTING>("int"|"integer") { > + return T_INT_HINT; > +} > + > +<ST_IN_SCRIPTING>("real"|"double"|"float") { > + return T_DOUBLE_HINT; > +} > + > <ST_IN_SCRIPTING>"++" { > return T_INC; > } > Index: ext/reflection/php_reflection.c > =================================================================== > RCS file: /repository/php-src/ext/reflection/php_reflection.c,v > retrieving revision 1.164.2.33.2.31 > diff -u -r1.164.2.33.2.31 php_reflection.c > --- ext/reflection/php_reflection.c 18 Oct 2006 16:35:15 -0000 1.164.2.33.2.31 > +++ ext/reflection/php_reflection.c 3 Nov 2006 13:28:52 -0000 > @@ -610,7 +610,7 @@ > if (arg_info->allow_null) { > string_printf(str, "or NULL "); > } > - } else if (arg_info->array_type_hint) { > + } else if (arg_info->type_hint == IS_ARRAY) { > string_printf(str, "array "); > if (arg_info->allow_null) { > string_printf(str, "or NULL "); > @@ -2015,7 +2015,7 @@ > METHOD_NOTSTATIC_NUMPARAMS(reflection_parameter_ptr, 0); > GET_REFLECTION_OBJECT_PTR(param); > > - RETVAL_BOOL(param->arg_info->array_type_hint); > + RETVAL_BOOL(param->arg_info->type_hint == IS_ARRAY); > } > /* }}} */ > >
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFUC8q1nS0RcInK9ARAlGJAKDYbYFx+dTJ3LxPNRPZ6U9TrRiRnACgtLHI 9PYtQ2ITyyhMxjWP27F5hoE= =PwDs -----END PGP SIGNATURE-----