Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.
In fact, it would make it harder. Many of the functions I work with
require varied input and almost always require some kind of validation
of that input. A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on an
inflatable chicken (at least the inflatable chicken extension has some
momentary amusement value).
Where is the increased value? Saving a few keystrokes of validation?
No. You still need to validate the input for range, or is_numeric() or
some other fancy business. Easier error handling? Most definitely
not. Most of the time, I throw an exception, how is an E_FATAL or
E_RECOVERABLE_ERROR going to help me here? False sense of security
because it limits input to a particular type? perhaps, but the key word
here is "false."
type hints might be more useful if they threw an exception, but even
then I would rather do that explicitly for the obvious reason that I may
not be the maintainer of my programs forever and someone else is going
to have to figure out why this exception was thrown. The backtrace will
reference an actual line number with the word "throw" on it if I do it
myself, and will be magical if not.
In short, could we please move on from type hinting, I am a big -1 for
so many reasons, it gives me gas just to think about them all at once.
Thanks,
Greg
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.In fact, it would make it harder. Many of the functions I work with
require varied input and almost always require some kind of validation
of that input. A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on an
You are missing the point.
If you want your function to take an argument of arbitrary type, then
you simply don't give a type hint[**]
[**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.
Where is the increased value? Saving a few keystrokes of validation?
No. You still need to validate the input for range, oris_numeric()or
No. The point is NOT to save input ($_GET, etc) validation -- that will
still need to be done; the point is to help pick up programming errors
where you accidentally get the type wrong.
Granted: some idiots will use it as cheap input validation, but it is difficult
to help some people.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.In fact, it would make it harder. Many of the functions I work with
require varied input and almost always require some kind of validation
of that input. A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on anYou are missing the point.
If you want your function to take an argument of arbitrary type, then
you simply don't give a type hint[**][**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.
I was thinking about this, a "mixed" type hint which doesn't do
anything. Would be very easy to add.
Where is the increased value? Saving a few keystrokes of validation?
No. You still need to validate the input for range, oris_numeric()orNo. The point is NOT to save input ($_GET, etc) validation -- that will
still need to be done; the point is to help pick up programming errors
where you accidentally get the type wrong.Granted: some idiots will use it as cheap input validation, but it is difficult
to help some people.
Exactly. This is not intended for $_REQUEST stuff. This is intended for
internal function interaction, configuration variables, etc. All
post/get data is inputted as strings, so this doesn't apply there.
Alain Williams wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.In fact, it would make it harder. Many of the functions I work with
require varied input and almost always require some kind of validation
of that input. A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on anYou are missing the point.
If you want your function to take an argument of arbitrary type, then
you simply don't give a type hint[**]
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.
Many users out there are confused about simple things like the result of
1 === "1" versus 1 == "1". The fact is that scalar types are simply not
strict enough to warrant a type hint. An object of class X is immutable
- you either have that or a subclass. An array is an array, and can't
look like anything else. Integers, floats, strings are much more gray
area, and much less likely to provide good, clear input to check against
a type hint.
Also, you and many who are in favor of type hints seem to forget that
part of PHP's strength is the ability to distribute and use code written
by other people. I guarantee that regardless of whether I choose to use
type hints, someone whose code I will have to use will be using type
hints, forcing me to deal with them. Imagine a program uses exceptions
for error handling, and you wish to use a library that has type hints.
Now, you can't catch problems using this program except via fatal error,
or worse, an error handler that has only a backtrace from which to grab
context.
[**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.Where is the increased value? Saving a few keystrokes of validation?
No. You still need to validate the input for range, oris_numeric()orNo. The point is NOT to save input ($_GET, etc) validation -- that will
still need to be done; the point is to help pick up programming errors
where you accidentally get the type wrong.
This is just the point that appears to be lost on advocates for scalar
type hints - this work of picking up programming errors should be
performed in development, not in production, and type hint as warning
does nothing to assist debugging. In the error log, there is no
backtrace, so all you know is that on line X in file Y invalid input was
passed to a function. No context, no reproduce steps, and no backtrace
to see the logic train.
Greg
Alain Williams wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.In fact, it would make it harder. Many of the functions I work with
require varied input and almost always require some kind of validation
of that input. A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on anYou are missing the point.
If you want your function to take an argument of arbitrary type, then
you simply don't give a type hint[**]But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.Many users out there are confused about simple things like the result of
1 === "1" versus 1 == "1". The fact is that scalar types are simply not
strict enough to warrant a type hint. An object of class X is immutable
- you either have that or a subclass. An array is an array, and can't
look like anything else. Integers, floats, strings are much more gray
area, and much less likely to provide good, clear input to check against
a type hint.Also, you and many who are in favor of type hints seem to forget that
part of PHP's strength is the ability to distribute and use code written
by other people. I guarantee that regardless of whether I choose to use
type hints, someone whose code I will have to use will be using type
hints, forcing me to deal with them. Imagine a program uses exceptions
for error handling, and you wish to use a library that has type hints.
Now, you can't catch problems using this program except via fatal error,
or worse, an error handler that has only a backtrace from which to grab
context.[**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.Where is the increased value? Saving a few keystrokes of validation?
No. You still need to validate the input for range, oris_numeric()orNo. The point is NOT to save input ($_GET, etc) validation -- that will
still need to be done; the point is to help pick up programming errors
where you accidentally get the type wrong.
This is just the point that appears to be lost on advocates for scalar
type hints - this work of picking up programming errors should be
performed in development, not in production, and type hint as warning
does nothing to assist debugging. In the error log, there is no
backtrace, so all you know is that on line X in file Y invalid input was
passed to a function. No context, no reproduce steps, and no backtrace
to see the logic train.
That's not true. You can easily set up your error handler to throw an
exception, which will provide a full backtrace.
And type hinting will help to catch these errors in development, rather
than finding out that all of your users have their email addresses
stored as "Array" in your database.
Greg
Good Morning everyone,
one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...
- the code gets smaller because not so many typechecks in every function
- because the code gets smaller it is faster executed (userspace
typecheck is slower than "engine-space") - without all these type checks the code gets easier to read
- with type hints byte code optimizer can optimize the code far better
-> faster execution - with type hints static analysing tools that check for
bugs/vulnerabilities can perform far better (intra procedural analysis
gives more information)
Stefan Esser
To add another two points to Stefan's argument. Type hinting does not
remove the need to filter user input, but it does allow you to safe-
guard internal functions (library code etc...) against accidental or
internal misuse or improper handling of the data in the front-end
layer. It also makes the code far more readable and understandable not
the mention help doc generation tools that interrogate the code.
Good Morning everyone,
one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...
- the code gets smaller because not so many typechecks in every
function- because the code gets smaller it is faster executed (userspace
typecheck is slower than "engine-space")- without all these type checks the code gets easier to read
- with type hints byte code optimizer can optimize the code far better
-> faster execution- with type hints static analysing tools that check for
bugs/vulnerabilities can perform far better (intra procedural analysis
gives more information)Stefan Esser
--
Ilia Alshanetsky
To add another two points to Stefan's argument. Type hinting does not
remove the need to filter user input, but it does allow you to safe-
guard internal functions (library code etc...) against accidental or
internal misuse or improper handling of the data in the front-end
layer. It also makes the code far more readable and understandable not
the mention help doc generation tools that interrogate the code.
Exactly, not input, but internal application code. For me a big thing is
configuration variables which are then used to call functions. It would
also help any other developers looking at your code (easier to
understand the purpose of arguments to a functions if it is type
hinted).
Good Morning everyone,
one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...
- the code gets smaller because not so many typechecks in every
function- because the code gets smaller it is faster executed (userspace
typecheck is slower than "engine-space")- without all these type checks the code gets easier to read
- with type hints byte code optimizer can optimize the code far better
-> faster execution- with type hints static analysing tools that check for
bugs/vulnerabilities can perform far better (intra procedural analysis
gives more information)Stefan Esser
--
Ilia Alshanetsky
layer. It also makes the code far more readable and understandable not
the mention help doc generation tools that interrogate the code.
I was under impression that it is good manners to actually document your
code and not rely on the tools to "interrogate" your code. Of course,
not everybody has good style, but I don't see much value in changing
language so that people writing in bad style would feel more comfortable.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
layer. It also makes the code far more readable and understandable
not the mention help doc generation tools that interrogate the code.I was under impression that it is good manners to actually document
your code and not rely on the tools to "interrogate" your code. Of
course, not everybody has good style, but I don't see much value in
changing language so that people writing in bad style would feel
more comfortable.
If you can offload type documentation you can make better use of your
time documenting the logic of the code, there is something to be said
about self documenting code especially when doing things like WSDL
generation.
Ilia Alshanetsky
I think the "mixed" identifier is a minor issue but I also don't see
it's purpose. If you don't want type hinting then don't write a type
hint. It's also tool friendly...
Andi
-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Friday, January 04, 2008 10:23 AM
To: Stas Malyshev
Cc: internals Mailing List
Subject: Re: [PHP-DEV] type hintinglayer. It also makes the code far more readable and understandable
not the mention help doc generation tools that interrogate the
code.I was under impression that it is good manners to actually document
your code and not rely on the tools to "interrogate" your code. Of
course, not everybody has good style, but I don't see much value in
changing language so that people writing in bad style would feel
more comfortable.If you can offload type documentation you can make better use of your
time documenting the logic of the code, there is something to be said
about self documenting code especially when doing things like WSDL
generation.Ilia Alshanetsky
I think the "mixed" identifier is a minor issue but I also don't see
it's purpose. If you don't want type hinting then don't write a type
hint. It's also tool friendly...
Andi
It is kind of pointless, just syntactic sugar to be honest. Not a big
deal at all though. I'd like it as I said for the syntactic sugar but
personally I don't care too much.
It is kind of pointless, just syntactic sugar to be honest. Not a big
More like syntactic used motor oil IMHO ;)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Look it boils down to the following:
True type enforcement ala === (i.e. you pass "1" to an int and it errors
out) does not make sense for PHP (and yes, philosophy and design goals
of the language are important). Forget even the argument that this is
not how PHP works all around and is inconsistent with what we've done
from day 1 but more importantly if you are going towards strict typing
then you need a type system to implement that during "compile-time"
(i.e. like C or Java). You otherwise loose out because you are pushing
out all these type problems into production and it'll lead to too many
production errors, often when it may not have to be an error.
What I suggested in my previous email is type hinting which also does
the conversion to the request type. This is very much in the PHP spirit
and also how PHP's internal functions work today. It is "consistent".
Copy&pasting from my previous email the following would work:
function iwantint(int $n) {
iwantint("1"); // "1" + 1 works great.
function iwantstring(string $str) {}
iwantstring($toStringObject); // Works in strcmp()
function iwantfloat(float $f) {}
iwantfloat(2);
function iwantbool(bool $b) {}
iwantbool(1);
But honestly adding strict type hinting ala (int === int) just does not
make sense in this language. There's a reason why C/Java are able to
enforce this at compile-time and don't push this equality into runtime.
It's not we are right or wrong vs. those languages it's that those
languages take it all the way and when requiring true strict typing they
do it right. In PHP this equates to extending PHP with C.
Andi
-----Original Message-----
From: Sam Barrow [mailto:sam@sambarrow.com]
Sent: Friday, January 04, 2008 10:49 AM
To: Andi Gutmans
Cc: Ilia Alshanetsky; Stas Malyshev; internals Mailing List
Subject: RE: [PHP-DEV] type hintingI think the "mixed" identifier is a minor issue but I also don't see
it's purpose. If you don't want type hinting then don't write a type
hint. It's also tool friendly...
AndiIt is kind of pointless, just syntactic sugar to be honest. Not a big
deal at all though. I'd like it as I said for the syntactic sugar but
personally I don't care too much.
Andi Gutmans wrote:
Look it boils down to the following:
True type enforcement ala === (i.e. you pass "1" to an int and it errors
out) does not make sense for PHP (and yes, philosophy and design goals
of the language are important).What I suggested in my previous email is type hinting which also does
the conversion to the request type. This is very much in the PHP
spirit and also how PHP's internal functions work today. It is
"consistent".
I agree (and did last time) with Andi about this. I am all for using a
== instead of === for type hinting scalars. This will mean any scalar
will pass as a string, but arrays and objects will not.
--
Brian Moon
Senior Developer
When you care enough to spend the very least.
http://dealnews.com/
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that. For every feature the first
question you need to ask yourselves is:
Will this make it easier or harder for the average PHP user to
build a web app? And if it makes it harder, is the extra pain
worth the benefit?
Given that HTTP is still the dominant web protocol and given that HTTP
is not typed, we have to be very careful about introducing stronger
typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
function isn't a use-case that can be easily dismissed as it was by
someone earlier. This is the primary use case. PHP takes scalar user
data which comes across HTTP untyped, does stuff to it, and sends
something back.
The argument that adding a type hint will make documentation easier is a
scary one for me. If we go and promote the use of runtime type hinting
in order for people to use auto-documentation tools, they are likely to
sprinkle these type hints everywhere which has the nasty side effect of
causing runtime warnings or errors when something returns 1 instead of
"1" whereas before this happily worked and worked correctly. And short
of fuzzing all your code, you aren't going to catch this case during
development.
The robustness principle holds true here:
Be conservative in what you do; be liberal in what you accept from
others.
This means that "1" and 1 should be able to travel freely within a PHP
script without tripping anything up. And it means there needs to be
ways for the code to be conservative in what it does with this data.
Today this generally means casting and context-specific filtering.
Robustness and code correctness play against each other to some extent.
If you wrote your code in such a way that a function should always be
passed 1 and not "1" then it might be nice to know when this isn't the
case, which is what type hinting is all about. PHP has always leaned
towards robustness, so having your code break in this case goes against
the spirit of PHP.
There are ways today to write code that is very strict in what it
accepts. It is possible that we can make it a bit easier to write this
style of code. But we have to keep this basic principle of PHP in mind
and also keep in mind that the type check is only a part (and usually
the fastest part) of the conservative data handling strategy. The
context-specific filtering, like making sure -1 doesn't turn into
2147483648 in some unsigned backend, still needs to happen with or
without type hints.
-Rasmus
Be conservative in what you do; be liberal in what you accept from
others.
You hopefully realise that this is exactly the opposite of your earlier
opinion that ext/filter should be used to block everything and let only
harmless data through. And only have raw data on demand...
I really don't understand why adding a new feature to the language
(that you can use or just not use and) that helps writing better code
and helps potential optimizers (that will come up as soon the feature is
implemented) to highly optimize the code get so much resistance...
Stefan Esser
Stefan Esser wrote:
Be conservative in what you do; be liberal in what you accept from
others.
You hopefully realise that this is exactly the opposite of your earlier
opinion that ext/filter should be used to block everything and let only
harmless data through. And only have raw data on demand...
Not at all. Filtering is about the contents of the data, not the scalar
type. It is only the most trivial of filtering that is solved by
typing. It is the value of the number or the contents of the string
that will trip you up, not whether it is a string or a number.
I really don't understand why adding a new feature to the language
(that you can use or just not use and) that helps writing better code
and helps potential optimizers (that will come up as soon the feature is
implemented) to highly optimize the code get so much resistance...
I'm not against it, but if it is implemented, it needs to make sense.
-Rasmus
Rasmus Lerdorf skrev:
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that.
There is one aspect that has popped up in the discussion about array
syntax but not here where it is almost as applicable.
ECMAScript 4 will have introduce optional strong typing. Not as type
hints in functions, but when one is declaring the variable as such.
Ergo: Web developers may very well start thinking more about types very
soon. Even if we are not talking about exactly the same thing for PHP.
The developers of Tamarin claim huge performance benefits. Stefan Esser
has predicted that type hints may facilitate speed improvements for PHP
as well.
Nobody has picked up on that thought, as far as I can see. If he is
right - and I am not in a position to say if he is or not - that would
count as a really strong argument, IMHO. A lot stronger than "less typing".
Lars Gunther
layer. It also makes the code far more readable and understandable
not the mention help doc generation tools that interrogate the code.I was under impression that it is good manners to actually document
your code and not rely on the tools to "interrogate" your code. Of
course, not everybody has good style, but I don't see much value in
changing language so that people writing in bad style would feel
more comfortable.
Well it would be much easier to type hint than to manually document
every one of your function parameters.
If you can offload type documentation you can make better use of your
time documenting the logic of the code, there is something to be said
about self documenting code especially when doing things like WSDL
generation.
Very good point.
Well it would be much easier to type hint than to manually document
every one of your function parameters.
How is this:
/* @param $client string Contains the name of the client for the account
is worse or less clear or harder to write that this:
processAccount(string $client)
Note that unless you write the former you code is still undocumented and
knowing it's a string won't help you much.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Well it would be much easier to type hint than to manually document
every one of your function parameters.How is this:
/* @param $client string Contains the name of the client for the account
is worse or less clear or harder to write that this:
processAccount(string $client)
Note that unless you write the former you code is still undocumented and
knowing it's a string won't help you much.
About the same, but the @param comment doesn't stop someone from putting
an array into $client.
About the same, but the @param comment doesn't stop someone from putting
an array into $client.
No, it doesn't. The function should handle that.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
About the same, but the @param comment doesn't stop someone from putting
an array into $client.No, it doesn't. The function should handle that.
Ok, in a bunch of extra unwanted code and a call to trigger_error(). Or
we could take the easy way and put "string" before the argument.
Good Morning everyone,
one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...
- the code gets smaller because not so many typechecks in every function
True.
- because the code gets smaller it is faster executed (userspace
typecheck is slower than "engine-space")
Very true, type hinting would be many times faster than using is_int,
etc. which puts to rest any argument that type hinting will be bad for
performance.
- without all these type checks the code gets easier to read
Yes, more concise and compact without manual type checking.
- with type hints byte code optimizer can optimize the code far better
-> faster execution- with type hints static analysing tools that check for
bugs/vulnerabilities can perform far better (intra procedural analysis
gives more information)
Also true. Applications like PHPDocumentor could make good use of scalar
type hints.
Stefan Esser
- the code gets smaller because not so many typechecks in every function
What do you mean "not so many"? You need one per checked parameter.
- because the code gets smaller it is faster executed (userspace
typecheck is slower than "engine-space")
If you need single-opcode-level speedups, you probably better off to
reimplement the same function in C. If we ever discover the speed of
is_integer is a huge problem, we can make it an operator. However, I so
far didn't see any evidence of that.
- with type hints byte code optimizer can optimize the code far better
Do you have any optimizer that can do that? Any plans to make one? Any
tests showing you can optimize real-life application this way?
- with type hints static analysing tools that check for
bugs/vulnerabilities can perform far better (intra procedural analysis
gives more information)
That is true, type hints do make static analysis easier - strict typing
is created exactly for that purpose. However, it only helps if all the
code is strictly typed - otherwise you just move point of failure
around. And in any case, type won't help you much form most real static
analysis purposes, such as security - "string" can hold anything.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
- the code gets smaller because not so many typechecks in every function
What do you mean "not so many"? You need one per checked parameter.
What's smaller, type checking with parameter type hinting, or manually
using is_int, is_string, etc?
What's smaller, type checking with parameter type hinting, or manually
using is_int, is_string, etc?
Smaller from what POV? Developer-side, it's the same - one check there,
one check here. Execution-side, since is_integer is a function and not
operation, it's a tiny bit slower, but as I said, if you got to this
level, you are looking for optimization in a wrong place.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev schrieb:
- the code gets smaller because not so many typechecks in every function
What do you mean "not so many"? You need one per checked parameter.
There is a difference in complexity between a userlevel type check and a
low level type check.- with type hints byte code optimizer can optimize the code far better
Do you have any optimizer that can do that? Any plans to make one? Any
tests showing you can optimize real-life application this way?
How should one have an optimizer for that as long PHP does not have this
feature? Noone would implement one that is capable of doing this not
knowing if the feature ever makes it into PHP.
That is true, type hints do make static analysis easier - strict
typing is created exactly for that purpose. However, it only helps if
all the code is strictly typed - otherwise you just move point of
failure around. And in any case, type won't help you much form most
real static analysis purposes, such as security - "string" can hold
anything.
That is not completely true. If for example 10 functions use type
hinting and other functions not, then you have atleast 10 functions
where you can analyse better.
A "simple" example is:
function decryptID($id)
{
return $id ^ SOME_RUNTIME_CONSTANT;
}
function getUserFromId($id)
{
$sql = "select * from user where id=".decrypt($id);
...
}
To analyse this construct a static code analyser has a lot todo and it
still needs to check every call to getUserFromId() to verify if this is
an actual security hole, because it doesn't know the content of
SOME_RUNTIME_CONSTANT and therefore the return value of decryptID could
be a binary xored string. However a type hint of int in the decryptID()
function would allow the analyser to know that decryptID() always return
int and this would tell it that this is not a security hole. You see in
this example that just partial usage of type hinting can mean the
difference between a false positive and a definitive unexploitability.
Greetings,
Stefan Esser
Stanislav Malyshev schrieb:
- the code gets smaller because not so many typechecks in every function
What do you mean "not so many"? You need one per checked parameter.
There is a difference in complexity between a userlevel type check and a
low level type check.
Definitely. User-level is 10 times more written code and is slower.
- with type hints byte code optimizer can optimize the code far better
Do you have any optimizer that can do that? Any plans to make one? Any
tests showing you can optimize real-life application this way?
How should one have an optimizer for that as long PHP does not have this
feature? Noone would implement one that is capable of doing this not
knowing if the feature ever makes it into PHP.
Very true, thank you for pointing that out.
That is true, type hints do make static analysis easier - strict
typing is created exactly for that purpose. However, it only helps if
all the code is strictly typed - otherwise you just move point of
failure around. And in any case, type won't help you much form most
real static analysis purposes, such as security - "string" can hold
anything.
That is not completely true. If for example 10 functions use type
hinting and other functions not, then you have atleast 10 functions
where you can analyse better.A "simple" example is:
function decryptID($id)
{
return $id ^ SOME_RUNTIME_CONSTANT;
}function getUserFromId($id)
{
$sql = "select * from user where id=".decrypt($id);
...
}To analyse this construct a static code analyser has a lot todo and it
still needs to check every call to getUserFromId() to verify if this is
an actual security hole, because it doesn't know the content of
SOME_RUNTIME_CONSTANT and therefore the return value of decryptID could
be a binary xored string. However a type hint of int in the decryptID()
function would allow the analyser to know that decryptID() always return
int and this would tell it that this is not a security hole. You see in
this example that just partial usage of type hinting can mean the
difference between a false positive and a definitive unexploitability.
In general, type hinting gives you more control over your code. Also, if
$id is an int, you prevent having to escape the data to avoid sql
injection.
Greetings,
Stefan Esser
There is a difference in complexity between a userlevel type check and a
low level type check.
Rather minimal.
How should one have an optimizer for that as long PHP does not have this
feature? Noone would implement one that is capable of doing this not
knowing if the feature ever makes it into PHP.
There are a lot of places where you can know and/or derive types right now.
To analyse this construct a static code analyser has a lot todo and it
still needs to check every call to getUserFromId() to verify if this is
an actual security hole, because it doesn't know the content of
SOME_RUNTIME_CONSTANT and therefore the return value of decryptID could
be a binary xored string. However a type hint of int in the decryptID()
function would allow the analyser to know that decryptID() always return
int and this would tell it that this is not a security hole. You see in
That provided you actually expected decryptID() to return int, which is
not obvious at all. But even then it's not an analyser problem -
analyzer should just tell the user he is using xor(unknown, unknown) and
recommend to do ((integer)$id)^RUNTIME_CONSTANT.
Anyway, I do not doubt you can find special cases where this function
could be useful. It is obvious that since you want this function you
have some use cases for it. However, I do doubt these cases are common
enough to make a difference - the fact that for ^ to be string both
operands should be strings is just a peculiar property of ^, you could
as well have a function there which could return string if only one of
operands were string. That does not improve general case, only some very
specific instances of some very specific cases.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.
Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
it. You still like to take care of any kind of types for your
arguments (with all associated magical pains and useless tests), you
can do it. That's not the case for use who likes to use stronger
arguments (and we are talking about arguments only here).
Cheers,
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
Read: othing will prevent you to >do not< use it :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
Read: othing will prevent you to >do not< use it :)
So you're saying if you don't like it just don't use it?
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
Read: othing will prevent you to >do not< use it :)
So you're saying if you don't like it just don't use it?
Yes, that's the meaning of "optional" I suppose :)
My idea about it (I did not test the patch, so correct me if I
misunderstood the proposal) was to leave the default as it is now:
function($a) > what Greg likes to always use ;)
function(mixed $a) > little syntax sugar, same as the previous one
function(int $a)
etc.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
Read: othing will prevent you to >do not< use it :)
So you're saying if you don't like it just don't use it?
Yes, that's the meaning of "optional" I suppose :)
My idea about it (I did not test the patch, so correct me if I
misunderstood the proposal) was to leave the default as it is now:function($a) > what Greg likes to always use ;)
function(mixed $a) > little syntax sugar, same as the previous one
function(int $a)
etc.
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.
Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
still work.
Hi Sam,
Am Freitag, den 04.01.2008, 12:11 -0500 schrieb Sam Barrow:
[...]
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.
[...]
To make your patch better you should add a bunch of test cases. Just a
test brainstorming:
* Current behaviour (no type hinting) works as expected
* Current behaviour for class type hinting works
* Scalar type hints are enforced to be lowercase ("Int" hints a
class, "int" a primitive)
* All new type hints work
* All new type hint aliases work
* All new type hints throw errors if wrong types are passed
* Meta type hints (like "mixed", "num", etc.) work
* Reflections on type hints work (foo(string $str);
ReflectionParam::getType() => "string",
ReflectionParam::isArray() => false and the like)
There are already a few test cases for type hinting in
tests/classes/type_hinting_*.phpt for you to look at.
cu, Lars
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
still work.
I notice that you use strcasecmp() to compare type name. I thought that we were moving
away from case independence, ie the type should be 'int' or perhaps 'INT' - whatever
we agree on it should have a defined capitalisation.
Just an off the wall thought ... if the type is not a known scalar type or class, then check to see if the
word is a constant ... could be interesting .... aka C's typedefs.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
still work.I notice that you use
strcasecmp()to compare type name. I thought that we were moving
away from case independence, ie the type should be 'int' or perhaps 'INT' - whatever
we agree on it should have a defined capitalisation.
Oh ok. Well I assumed it would be case sensitive like variables but you
do have a point, many keywords in PHP are not case sensitive. This is
something that can be easily changed depending on what people want.
Just an off the wall thought ... if the type is not a known scalar type or class, then check to see if the
word is a constant ... could be interesting .... aka C's typedefs.
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
still work.I notice that you use
strcasecmp()to compare type name. I thought that we were moving
away from case independence, ie the type should be 'int' or perhaps 'INT' - whatever
we agree on it should have a defined capitalisation.
Sorry I was confused about what you were saying in my previous response,
I have changed it to strcmp, for lowercase only.
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.
IMO adding new type hint for the sole purpose of having some string next
to the variable is just silly. If you need documentation, use documentation.
Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
Do you realize that hinting variable as "object" or "resource" has no
meaning, since resources and objects are not interchangeable and you
never want just "object" or "resource" - you want object of particular
class and resource of particular type?
Also, what use case might there be for "scalar"?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.IMO adding new type hint for the sole purpose of having some string next
to the variable is just silly. If you need documentation, use documentation.Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hintsDo you realize that hinting variable as "object" or "resource" has no
meaning, since resources and objects are not interchangeable and you
never want just "object" or "resource" - you want object of particular
class and resource of particular type?
Not necessarily, if you have a function that performs a generic
operation on any object. As for resources you are right, it might be
ideal to have "mysql resource" rather than just "resource", but just
having the "resource" type hint is better than having no type hint.
Also, what use case might there be for "scalar"?
This is one that I find very useful, much more than it may seem. I use
scalar for any type of post/get input, printed output, or DB
interaction, as objects/arrays/resources cannot be printed or stored in
a database in a standardized way.
Not necessarily, if you have a function that performs a generic
operation on any object. As for resources you are right, it might be
Like what? I don't know many operations that are good for any object and
only object and need special function to perform them. Actually,
excluding scenarios like serialization and RPC (which should take care
of other types too so irrelevant here) I can't think of any right now.
ideal to have "mysql resource" rather than just "resource", but just
having the "resource" type hint is better than having no type hint.
No, it's not better. Having GD image instead of mysql connection is not
better than having integer in any way. It would just produce different
error message, so what?
This is one that I find very useful, much more than it may seem. I use
scalar for any type of post/get input, printed output, or DB
interaction, as objects/arrays/resources cannot be printed or stored in
a database in a standardized way.
If you need serialization/printing, you have serialize() and
__toString() with respective handlers. If you reimplementing them and
using scalar restrictions, you most probably do it wrong.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Not necessarily, if you have a function that performs a generic
operation on any object. As for resources you are right, it might beLike what? I don't know many operations that are good for any object and
only object and need special function to perform them. Actually,
excluding scenarios like serialization and RPC (which should take care
of other types too so irrelevant here) I can't think of any right now.ideal to have "mysql resource" rather than just "resource", but just
having the "resource" type hint is better than having no type hint.No, it's not better. Having GD image instead of mysql connection is not
better than having integer in any way. It would just produce different
error message, so what?
That's actually very true.
This is one that I find very useful, much more than it may seem. I use
scalar for any type of post/get input, printed output, or DB
interaction, as objects/arrays/resources cannot be printed or stored in
a database in a standardized way.If you need serialization/printing, you have
serialize()and
__toString() with respective handlers. If you reimplementing them and
using scalar restrictions, you most probably do it wrong.
Ok but if someone inputs an array in the query string i have a problem
with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string "Array" instead once you handle it.
If it's a problem, then having "Array" from the start is a problem too.
with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.
Object serialization is very standardized, it has proper handlers, etc.
As for outputting arrays, indeed, 'Array' is not very meaningful, but
would "Incompatible type is call in function foo() /foo/bar.php line
123" be better?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string "Array" instead once you handle it.
If it's a problem, then having "Array" from the start is a problem too.
Yes, and the type hint will catch this problem in a second.
with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.Object serialization is very standardized, it has proper handlers, etc.
As for outputting arrays, indeed, 'Array' is not very meaningful, but
would "Incompatible type is call in function foo() /foo/bar.php line
123" be better?
Yes it would. Because the developer would fix the error upon seeing an
error message like that, and avoid the entire future problem. Do you
suggest letting the bug go unnoticed until it causes real damage?
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string "Array" instead once you handle it.
If it's a problem, then having "Array" from the start is a problem too.with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.Object serialization is very standardized, it has proper handlers, etc.
As for outputting arrays, indeed, 'Array' is not very meaningful, but
would "Incompatible type is call in function foo() /foo/bar.php line
123" be better?
Are you recomanding to use E_NOTICE and higher level with display_errors on? =)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string "Array" instead once you handle it.
If it's a problem, then having "Array" from the start is a problem too.with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.
By standardized I mean a visual representation of the object. A
serialized object will look to a web site visitor like complete garbage.
Object serialization is very standardized, it has proper handlers, etc.
As for outputting arrays, indeed, 'Array' is not very meaningful, but
would "Incompatible type is call in function foo() /foo/bar.php line
123" be better?Are you recomanding to use
E_NOTICEand higher level with display_errors on? =)</runninginciricle
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string "Array" instead once you handle it.
If it's a problem, then having "Array" from the start is a problem too.with that. And I said standardized way, ie bool true outputs as "1",
float 5.20 outputs as "5.2". For objects, toString is a standardized
output but serialization is not, and for arrays no standardized output
exists.Object serialization is very standardized, it has proper handlers, etc.
As for outputting arrays, indeed, 'Array' is not very meaningful, but
would "Incompatible type is call in function foo() /foo/bar.php line
123" be better?
I'd prefer that than have garbage in the database.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
I'd prefer that than have garbage in the database.
If your application drops dead in the middle of work because some handle
can't process the data your database probably won't be in the best shape
anyway.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I'd prefer that than have garbage in the database.
If your application drops dead in the middle of work because some handle
can't process the data your database probably won't be in the best shape
anyway.
Yes, it drops dead, I get a phone call, it's fixed and running properly
10 minutes later. In your case it could be months before we find that
there's "Array" in one of our database fields. Maybe it's not an
important field or anything... like tax or something :|
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
marcus
Friday, January 4, 2008, 5:53:56 PM, you wrote:
But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
Read: othing will prevent you to >do not< use it :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Best regards,
Marcus
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?
<?php
function foo( require int $a, require string $b ){}
foo( '5', 'bleh' ); // <-- fatal error
?>
Contrast versus:
<?php
function foo( int $a, string $b ){}
foo( '5', 'bleh' ); // <-- no exception or error $a in foo() will
// be type int (automatic conversion)
?>
Versus (still allowed default style):
<?php
function foo( $a, $b ){}
foo( '5', 'bleh' ); // <-- no exceptions or type conversions
?>
Thoughts?
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?
I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.
<?php
function foo( require int $a, require string $b ){}
foo( '5', 'bleh' ); // <-- fatal error
?>
Contrast versus:
<?php
function foo( int $a, string $b ){}
foo( '5', 'bleh' ); // <-- no exception or error $a in foo() will
// be type int (automatic conversion)?>
Versus (still allowed default style):
<?php
function foo( $a, $b ){}
foo( '5', 'bleh' ); // <-- no exceptions or type conversions
?>
Thoughts?
Cheers,
Rob............................................................
SwarmBuy.com - http://www.swarmbuy.comLeveraging the buying power of the masses!...........................................................
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.
I think that depends on what I do with the variable. PHP doesn't know
how I intend to use it, and if I know I want an int and I don't want to
test for browserland garbage in my variable everytime the function is
called, then an automatic type conversion to int for my function can
make perfect sense. Yes, I could force the developer using my function
to cast the parameter as an int, but I'm certain conversion in the
engine without a userland cast is faster, and it makes it more
convenient to the consumer of my function since they can still treat it
like a classic function.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.I think that depends on what I do with the variable. PHP doesn't know
how I intend to use it, and if I know I want an int and I don't want to
test for browserland garbage in my variable everytime the function is
called, then an automatic type conversion to int for my function can
make perfect sense. Yes, I could force the developer using my function
to cast the parameter as an int, but I'm certain conversion in the
engine without a userland cast is faster, and it makes it more
convenient to the consumer of my function since they can still treat it
like a classic function.
Yes, but whatever you do with it (echo, store in db, etc.) PHP will
perform its default conversion routine for the variable type. You have a
point though, this is something that I've actually been debating for
some time:
function a(int $a, cast int $b) {
}
$a must be an int
$b will be cast to an int
I just think this is getting a little bit too complicated. Many people
on here are resistant enough to scalar type hinting because they say
it's confusing, they'll definitely be even more resistant to something
like this.
Cheers,
Rob.
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.I think that depends on what I do with the variable. PHP doesn't know
how I intend to use it, and if I know I want an int and I don't want to
test for browserland garbage in my variable everytime the function is
called, then an automatic type conversion to int for my function can
make perfect sense. Yes, I could force the developer using my function
to cast the parameter as an int, but I'm certain conversion in the
engine without a userland cast is faster, and it makes it more
convenient to the consumer of my function since they can still treat it
like a classic function.Yes, but whatever you do with it (echo, store in db, etc.) PHP will
perform its default conversion routine for the variable type. You have a
point though, this is something that I've actually been debating for
some time:function a(int $a, cast int $b) {
}
$a must be an int
$b will be cast to an int
Yes, that makes more sense since it brings things in line with the
current semantics for array/object type hinting.
I just think this is getting a little bit too complicated. Many people
on here are resistant enough to scalar type hinting because they say
it's confusing, they'll definitely be even more resistant to something
like this.
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a "complicated feature" then they shouldn't. I
don't think cutting the legs out from developers who want to use said
features is the solution. I mean we're all programmers around here... is
it really that complicated? Required paraneter types, automatic
parameter casting, and ad-hoc paramets types? :)
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a "complicated feature" then they shouldn't. I
Not an argument.
don't think cutting the legs out from developers who want to use said
features is the solution. I mean we're all programmers around here... is
Omitting feature that wasn't in PHP for 10 years and all developers were
OK with it is not "cutting legs out".
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a "complicated feature" then they shouldn't. INot an argument.
don't think cutting the legs out from developers who want to use said
features is the solution. I mean we're all programmers around here... isOmitting feature that wasn't in PHP for 10 years and all developers were
OK with it is not "cutting legs out".
Well PHP is changing into an enterprise-level language now. Out with the
old, in with the new. And I'm sure there were some developers who did
want this feature but didn't necessarily say anything.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Well PHP is changing into an enterprise-level language now. Out with the
What is "enterprise-level language"?
old, in with the new. And I'm sure there were some developers who did
want this feature but didn't necessarily say anything.
So what? There are developers that don't want this feature and didn't
say anything.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Well PHP is changing into an enterprise-level language now. Out with the
What is "enterprise-level language"?
A language that can be used for large scale applications, with tons of
extensions for integration with many third party applications and
protocols. PHP is no longer a form submitter/emailer.
old, in with the new. And I'm sure there were some developers who did
want this feature but didn't necessarily say anything.So what? There are developers that don't want this feature and didn't
say anything.
Ok... You said that nobody wanted this feature. I'm saying how do you
know that, I'm sure there are some people that did.
A language that can be used for large scale applications, with tons of
extensions for integration with many third party applications and
protocols. PHP is no longer a form submitter/emailer.
Hey, you are right, it isn't! It is actually used right now for "large
scale applications, with tons of extensions for integration with many
third party applications".
Ok... You said that nobody wanted this feature. I'm saying how do you
I didn't. I said everybody was fine without this feature. It's
different. I may "want" to have a BMW 335i convertible (especially if
somebody donates it to me for free :), but I'm doing fine without it and
do not plan to spend money on buying one soon. :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
A language that can be used for large scale applications, with tons of
extensions for integration with many third party applications and
protocols. PHP is no longer a form submitter/emailer.Hey, you are right, it isn't! It is actually used right now for "large
scale applications, with tons of extensions for integration with many
third party applications".Ok... You said that nobody wanted this feature. I'm saying how do you
I didn't. I said everybody was fine without this feature. It's
different. I may "want" to have a BMW 335i convertible (especially if
somebody donates it to me for free :), but I'm doing fine without it and
do not plan to spend money on buying one soon. :)
Good point. We were fine before OO and exceptions too weren't we.
Good point. We were fine before OO and exceptions too weren't we.
No, actually we weren't as fine. OO allowed for application frameworks
and libraries to flourish.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Good point. We were fine before OO and exceptions too weren't we.
No, actually we weren't as fine. OO allowed for application frameworks
and libraries to flourish.
Now that we have them, we can help them become more robust by allowing
them to decide how their APIs should be used.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Robert Cummings wrote:
| On Fri, 2008-01-04 at 11:52 -0800, Stanislav Malyshev wrote:
|>> Good point. We were fine before OO and exceptions too weren't we.
|> No, actually we weren't as fine. OO allowed for application frameworks
|> and libraries to flourish.
|
| Now that we have them, we can help them become more robust by allowing
| them to decide how their APIs should be used.
This is very I see the strongest case for type hints. Framework,
Libraries, Components, WhatEverYouCallThem. Especially for remote APIs
type hints can help a lot, I think.
-
- Markus
ps: Do the 24 hours already count?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHfp8V1nS0RcInK9ARAgqYAKCt9xGZDCuubTJCVr8iluvHalJ45gCguiVu
AZzNl6ek9tDZcbK4jnHMr2A=
=8I6u
-----END PGP SIGNATURE
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a "complicated feature" then they shouldn't. INot an argument.
don't think cutting the legs out from developers who want to use said
features is the solution. I mean we're all programmers around here... isOmitting feature that wasn't in PHP for 10 years and all developers were
OK with it is not "cutting legs out".
You are right. I should have written... I don't think preventing
developers from building a stronger foundation upon which they can stand
is the solution.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
You are right. I should have written... I don't think preventing
developers from building a stronger foundation upon which they can stand
is the solution.
Nobody prevents you from building any foundation. I am convinced that in
fact using of typehints as proposed now would lead to worse, not better
foundation.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.I think that depends on what I do with the variable. PHP doesn't know
how I intend to use it, and if I know I want an int and I don't want to
test for browserland garbage in my variable everytime the function is
called, then an automatic type conversion to int for my function can
make perfect sense. Yes, I could force the developer using my function
to cast the parameter as an int, but I'm certain conversion in the
engine without a userland cast is faster, and it makes it more
convenient to the consumer of my function since they can still treat it
like a classic function.Yes, but whatever you do with it (echo, store in db, etc.) PHP will
perform its default conversion routine for the variable type. You have a
point though, this is something that I've actually been debating for
some time:function a(int $a, cast int $b) {
}
$a must be an int
$b will be cast to an intYes, that makes more sense since it brings things in line with the
current semantics for array/object type hinting.I just think this is getting a little bit too complicated. Many people
on here are resistant enough to scalar type hinting because they say
it's confusing, they'll definitely be even more resistant to something
like this.It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a "complicated feature" then they shouldn't. I
don't think cutting the legs out from developers who want to use said
features is the solution. I mean we're all programmers around here... is
it really that complicated? Required paraneter types, automatic
parameter casting, and ad-hoc paramets types? :)
I agree with you 100% here, I just don't think the PHP development team
is going to be wiling to implement it, since they are very big on
keeping it easy for beginners. I agree with you 100% though, I'm just
saying that in the situation it's probably not going to happen.
Cheers,
Rob.
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it.
We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the
OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type
hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that
has
type hinting to ensure their data is of the correct type. This
prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Fatal error is a no no. This goes back to my argument of why
exceptions do not fit the PHP development process as uncaught
exceptions are also fatal errors. The reason is that PHP is great
because it works as good as is reomotely possible with the given code.
Look at SugarCRM, the code is horrific, yet it works (more or less).
This is especially a concern for me when doing refactoring types are
surely going to mismatch during the process, but as I test some parts
of my changes, I do not want the entire application to fail until I
complete my refactoring.
Fatal errors everywhere are a nice way to beat developers to write
finished code from day one (or actually before any refresh), which
matches the development style how exactly how many PHP developers?
But we are only talking about an E_RECOVERABLE. That being said the
argument brought up by Greg about the lack of context still applies so
maybe it should just be a warning or whatever ..
regards,
Lukas
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it.
We do this
for a reason. That is we only want to support mainstream features.My point of view is that this feature should be a mainstream feature.
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the
OO
strictness.IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type
hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that
has
type hinting to ensure their data is of the correct type. This
prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.Fatal error is a no no. This goes back to my argument of why
exceptions do not fit the PHP development process as uncaught
exceptions are also fatal errors. The reason is that PHP is great
because it works as good as is reomotely possible with the given code.
Look at SugarCRM, the code is horrific, yet it works (more or less).
This is especially a concern for me when doing refactoring types are
surely going to mismatch during the process, but as I test some parts
of my changes, I do not want the entire application to fail until I
complete my refactoring.Fatal errors everywhere are a nice way to beat developers to write
finished code from day one (or actually before any refresh), which
matches the development style how exactly how many PHP developers?But we are only talking about an E_RECOVERABLE. That being said the
argument brought up by Greg about the lack of context still applies so
maybe it should just be a warning or whatever ..
You are right, E_RECOVERABLE is a much better option.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?<?php
function foo( require int $a, require string $b ){}
foo( '5', 'bleh' ); // <-- fatal error
No.
?>
Contrast versus:
<?php
function foo( int $a, string $b ){}
foo( '5', 'bleh' ); // <-- no exception or error $a in foo() will
// be type int (automatic conversion)
Yes. If $a is '5' but reject if $a is '5five'.
?>
Versus (still allowed default style):
<?php
function foo( $a, $b ){}
foo( '5', 'bleh' ); // <-- no exceptions or type conversions
?>
Thoughts?
Cheers,
Rob............................................................
SwarmBuy.com - http://www.swarmbuy.comLeveraging the buying power of the masses!...........................................................
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?<?php
function foo( require int $a, require string $b ){}
foo( '5', 'bleh' ); // <-- fatal error
No.
?>
Contrast versus:
<?php
function foo( int $a, string $b ){}
foo( '5', 'bleh' ); // <-- no exception or error $a in foo() will
// be type int (automatic conversion)Yes. If $a is '5' but reject if $a is '5five'.
This is what I was considering, but to do something like this we will
have to implement a whole separate rule set just for type hint
conversion.
?>
Versus (still allowed default style):
<?php
function foo( $a, $b ){}
foo( '5', 'bleh' ); // <-- no exceptions or type conversions
?>
Thoughts?
Cheers,
Rob............................................................
SwarmBuy.com - http://www.swarmbuy.comLeveraging the buying power of the masses!...........................................................
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
type hinting to ensure their data is of the correct type. This prevents
accidental wrong data conversion. However, I see the other side of the
coin too where automatic type conversion could be desirable also.
Perhaps a mixed solution would be viable?<?php
function foo( require int $a, require string $b ){}
foo( '5', 'bleh' ); // <-- fatal error
No.
?>
Contrast versus:
<?php
function foo( int $a, string $b ){}
foo( '5', 'bleh' ); // <-- no exception or error $a in foo() will
// be type int (automatic conversion)Yes. If $a is '5' but reject if $a is '5five'.
This is what I was considering, but to do something like this we will
have to implement a whole separate rule set just for type hint
conversion.
Personally I think it's a bit silly to allow '5' and reject '5five'. The
following is fairly standard behaviour in PHP:
<?php
echo 'Foo: '.(0 + '5five')."\n";
echo 'Foo: '.((int)'5five')."\n";
echo 'Foo: '.(intval( ' 5five' ))."\n";
echo 'Foo: '.(sprintf( '%d', '5five' ))."\n";
?>
All produce 5.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
So you code could blow up in random places in production because
somebody wrote a plugin that called a typehinted class with wrong
variable type (and remember, PHP has no variable typing, so you have no
idea what type of the variable is in each particular place) without
properly wrapping it.
type hinting to ensure their data is of the correct type. This prevents
Doing this how? Without full variable typing and static type control you
can not do it.
accidental wrong data conversion. However, I see the other side of the
No, it doesn't. It makes your application blow up on data conversion. I
would prefer having '1' converted to 1 instead of having my application
fail.
function foo( require int $a, require string $b ){}
So now we have 2 additional syntaxes instead of one...
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.
OO mandates you to work in certain way. However, the way PHP works with
values was never type-strict and there's no reason to suddenly change
PHP into type-strict language.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.OO mandates you to work in certain way. However, the way PHP works with
values was never type-strict and there's no reason to suddenly change
PHP into type-strict language.
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.
For type hinting that you propose to work, you need to change PHP into
type-strict language.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.For type hinting that you propose to work, you need to change PHP into
type-strict language.
No, you don't. I could swear I've been using scalar type hinting for
about a month and a half now, and I don't remember changing PHP into a
strictly typed language.
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.For type hinting that you propose to work, you need to change PHP into
type-strict language.
Now we don't. We've already shown how it would work without PHP being
converted to type strict language... ergo you're assertion is untrue.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
Hi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even better is if you could summarize the discussion (both sides) and
put this up on a website. If you want you can use my release
management wiki.
Thanks for 24 hours of peace on this topic ..
regards,
Lukas
Ok deal.
Hi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even better is if you could summarize the discussion (both sides) and
put this up on a website. If you want you can use my release
management wiki.Thanks for 24 hours of peace on this topic ..
regards,
Lukas
At least I suggest that people limit themselves to max 1 email per hour
(incl. Stas & Sam) - preferably 2-3 per day. Just take a 1-2 hour
breather after you've sent an email and then read the whole thread that
comes back and answer multiple arguments in one email.
Seriously, the person answering most often and quickest is not going to
win this debate :)
Andi
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Friday, January 04, 2008 12:19 PM
To: Robert Cummings
Cc: Stas Malyshev; Sam Barrow; Pierre; internals Mailing List
Subject: Re: [PHP-DEV] type hintingHi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even better is if you could summarize the discussion (both sides) and
put this up on a website. If you want you can use my release
management wiki.Thanks for 24 hours of peace on this topic ..
regards,
Lukas
I'm not gonna start the discussion about making this list read-only again, maybe
it's just enough that Stas is not allowed to post? :D
Anyway, who dropped the word "OPTIONAL" from the subject? I think that was quite
essential part of this whole debate? As I'm +1 for OPTIONAL scalar-type hinting.
It would have saved me some hours of debugging to find a very stupid mistake I
made this week at work..
--Jani
Andi Gutmans kirjoitti:
At least I suggest that people limit themselves to max 1 email per hour
(incl. Stas & Sam) - preferably 2-3 per day. Just take a 1-2 hour
breather after you've sent an email and then read the whole thread that
comes back and answer multiple arguments in one email.
Seriously, the person answering most often and quickest is not going to
win this debate :)Andi
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Friday, January 04, 2008 12:19 PM
To: Robert Cummings
Cc: Stas Malyshev; Sam Barrow; Pierre; internals Mailing List
Subject: Re: [PHP-DEV] type hintingHi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even better is if you could summarize the discussion (both sides) and
put this up on a website. If you want you can use my release
management wiki.Thanks for 24 hours of peace on this topic ..
regards,
Lukas
On Jan 5, 2008 1:52 AM, Jani Taskinen jani.taskinen@sci.fi kirjoitti:
Anyway, who dropped the word "OPTIONAL" from the subject? I think that was quite
essential part of this whole debate? As I'm +1 for OPTIONAL scalar-type hinting.
+1 on scalar-type-hinting (not to be confused with type-casting)
-Hannes
On Jan 5, 2008 1:52 AM, Jani Taskinen jani.taskinen@sci.fi kirjoitti:
Anyway, who dropped the word "OPTIONAL" from the subject? I think that was quite
essential part of this whole debate? As I'm +1 for OPTIONAL scalar-type hinting.+1 on scalar-type-hinting (not to be confused with type-casting)
I'm also +1 for optional scalar-type hinting FWIW.
Magnus
2008/1/4, Jani Taskinen jani.taskinen@sci.fi:
As I'm +1 for OPTIONAL scalar-type hinting.
me too +1 as long as :
<?php
function foo(int $a) {}
foo('5');
?>
Raises an error, and is rejected because is not a valid integer, otherwise -1
2008/1/4, Jani Taskinen jani.taskinen@sci.fi:
As I'm +1 for OPTIONAL scalar-type hinting.
me too +1 as long as :
<?php
function foo(int $a) {}
foo('5');
?>
Raises an error, and is rejected because is not a valid integer, otherwise -1
Agreed, this is the current behavior of the patch.
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
What about array and class type hinting? That's optional.
Alain Williams wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.In fact, it would make it harder. Many of the functions I work with
require varied input and almost always require some kind of validation
of that input. A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on anYou are missing the point.
If you want your function to take an argument of arbitrary type, then
you simply don't give a type hint[**]But I don't want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling. The current situation in
PHP provides a much more flexible solution to the same problem.
Are you suggesting that if a function requires an integer, string, and
object, we use is_int, is_string, and is_object to trigger errors? What
if we have 50 functions like this?
With type hinting:
function a(int $a, string $b, object $c) {
}
Without type hinting:
function a($a, $b, $c) {
if (!is_int($a)) {
trigger_error(E_WHATEVER, 'Argument 1 to function a() must be an
integer.') ;
}
if (!is_string($b)) {
trigger_error(E_WHATEVER, 'Argument 2 to function a() must be an
integer.') ;
}
if (!is_object($c)) {
trigger_error(E_WHATEVER, 'Argument 3 to function a() must be an
integer.') ;
}
}
[**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.
And the purpose of that exercise would be?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Afternoon,
Wow, go away for a weekend and look what happens...
Personally I think the issue is that true "scalar" type hinting doesn't
make much sense with a dynamically typed language. Deciding if/when/how
to juggle a scalar typehint is going to make at least one person angry
and some new user confused.
However, I have to agree with the fact that the current typehinting
system feels "unfinished". I can tell a function that it has to be
passed an array or some specific type of object, but can't tell it that
it has to be passed a scalar type, or a resource, or any generic object.
These don't "juggle" well like the generic scalar (int, bool, float,
string) types. Is there any reason we can't at least add "scalar" and
"resource" (and possibly "object" for generic objects) to typehints? It
wouldn't be the full "scalar typehinting" solution that people are
yelling for, but it would cut out lines of bad input handling in my own
code, and make the current typehint solution feel more complete.
My own $0.02,
Elizabeth Smith
Afternoon,
Wow, go away for a weekend and look what happens...
Personally I think the issue is that true "scalar" type hinting doesn't
make much sense with a dynamically typed language. Deciding if/when/how
to juggle a scalar typehint is going to make at least one person angry
and some new user confused.However, I have to agree with the fact that the current typehinting
system feels "unfinished". I can tell a function that it has to be
passed an array or some specific type of object, but can't tell it that
it has to be passed a scalar type, or a resource, or any generic object.These don't "juggle" well like the generic scalar (int, bool, float,
string) types. Is there any reason we can't at least add "scalar" and
"resource" (and possibly "object" for generic objects) to typehints? It
wouldn't be the full "scalar typehinting" solution that people are
yelling for, but it would cut out lines of bad input handling in my own
code, and make the current typehint solution feel more complete.
Scalar, resource, and object type hints would be very useful, and fit
perfectly with the current type juggling system. I still support all of
the hints, but these 3 alone have an even stronger argument than the
other ones.
My own $0.02,
Elizabeth Smith