[PATCH] Scalar type hinting ;)

18 years ago by Pierre — view source

unread

Hello,

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

18 years ago by Marcus Boerger — view source

unread

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,

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

18 years ago by Pierre — view source

unread

Hello,

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

18 years ago by Zeev Suraski — view source

unread

At 11:12 03/11/2006, Pierre wrote:

Hello,

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

18 years ago by Ron Korving — view source

unread

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

Hello,

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

18 years ago by Brian Moon — view source

unread

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

18 years ago by Ilia Alshanetsky — view source

unread

Hannes,

As much as I like the concept I would prefer to hold it off until the
next minor release or PHP6.

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>

Ilia Alshanetsky

18 years ago by Richard Lynch — view source

unread

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?

18 years ago by Richard Quadling — view source

unread

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!"

18 years ago by Ron Korving — view source

unread

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!"

18 years ago by Richard Quadling — view source

unread

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!"

--

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

18 years ago by Richard Lynch — view source

unread

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?

18 years ago by Richard Quadling — view source

unread

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

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
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

18 years ago by Christian Schneider — view source

unread

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

18 years ago by Richard Quadling — view source

unread

Error: Incompatible use of constant 'we'

"us" didn't make any sense!

Maybe y'all, or everyone would have been better.

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Markus Fischer — view source

unread

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

[PATCH] Scalar type hinting ;)

Brian Moon

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

--

--

--

--

--

--

Index: Zend/zend_API.h

Index: Zend/zend_compile.h

Index: Zend/zend_language_scanner.l

<ST_IN_SCRIPTING>"++" {
return T_INC;
}
Index: ext/reflection/php_reflection.c

[PATCH] Scalar type hinting ;)

Brian Moon

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

--

--

--

--

--

--

Index: Zend/zend_API.h

Index: Zend/zend_compile.h

Index: Zend/zend_language_scanner.l

<ST_IN_SCRIPTING>"++" { return T_INC; } Index: ext/reflection/php_reflection.c

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

<ST_IN_SCRIPTING>"++" {
return T_INC;
}
Index: ext/reflection/php_reflection.c