Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi,
From a user perspective, I agree that this would probably be the most useful
behaviour of all. Type hint would then mean*:
Hint at what type the variable should have. If possible, convert it to the
target type; if it is not even compatible, throw an error*.
Regards,
Guillaume Rossolini
On Thu, Jun 19, 2008 at 6:08 PM, Saulo Vallory [EMAIL PROTECTED]
wrote:
What if by type hint a parameter, php automatically tries to convert the
argument into that type and throws an exception ONLY if it couldn't be
done?
for example:
function concat(string $a, string $b)
{
return $a.$b;
}
I can do:
concat(1,'1');
concat(2.5,' pigs');
concat(new ConvertibleToStringObject, 15);
But if I do:
concat(new NonConvertibleToStringObject, 15);
PHP throws an exception saying the function needs a string, but the
parameter couldn't be converted...
Can this make everybody happy?
Cheers,
Saulo Vallory
On Wed, Jun 18, 2008 at 9:30 PM, Edward Z. Yang
[EMAIL PROTECTED] wrote:
Fabrice VIGNALS wrote:
In mathematic, equal meen the same value AND the same nature.
The follow fact could be frustrating :
Usually, context is good enough to disambiguate between the cases. The
most prevalent convention in programming languages is = is assignment,
and == is comparison (PHP adds === only because of its type-juggling
system). Other languages have = as comparison, and := as assignment.
Donald Knuth uses = as comparison, and a left arrow (-) for assignment.
--
Edward Z. YangGnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-06-19 at 20:07 +0200, Timm Friebe wrote: Hi, I like this generally, but cannot live with the BC issues raised. Introducing all type names as keywords will make class Object, class Integer and so on give a syntax error. That's actually not true, the patch does not introduce new keywords. Hrm, the Wiki states it does: http://wiki.php.net/rfc/typehint#bc_break1 If this can be worked out by other means, cool:) Sorry, you're right. I was talking about my patch for argument type hints, it doesn't create any new keywords. - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
What if by type hint a parameter, php automatically tries to convert the
argument into that type and throws an exception ONLY if it couldn't be done?
for example:
function concat(string $a, string $b)
{
return $a.$b;
}
I can do:
concat(1,'1');
concat(2.5,' pigs');
concat(new ConvertibleToStringObject, 15);
But if I do:
concat(new NonConvertibleToStringObject, 15);
PHP throws an exception saying the function needs a string, but the
parameter couldn't be converted...
Can this make everybody happy?
Cheers,
Saulo Vallory
On Wed, Jun 18, 2008 at 9:30 PM, Edward Z. Yang
[EMAIL PROTECTED] wrote:
Fabrice VIGNALS wrote:
In mathematic, equal meen the same value AND the same nature.
The follow fact could be frustrating :
Usually, context is good enough to disambiguate between the cases. The
most prevalent convention in programming languages is = is assignment,
and == is comparison (PHP adds === only because of its type-juggling
system). Other languages have = as comparison, and := as assignment.
Donald Knuth uses = as comparison, and a left arrow (-) for assignment.
--
Edward Z. YangGnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi, I like this generally, but cannot live with the BC issues raised. Introducing all type names as keywords will make class Object, class Integer and so on give a syntax error. That's actually not true, the patch does not introduce new keywords. Hrm, the Wiki states it does: http://wiki.php.net/rfc/typehint#bc_break1 If this can be worked out by other means, cool:) - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
In mathematic, equal meen the same value AND the same nature. The follow fact could be frustrating : Code : ? php echo 'you must understand than 1 + 1 = 2' ? Output : you must understand than 2 = 2 - Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Chris Stockton [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Monday, June 16, 2008 11:02 PM Subject: Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value) Hi! Maybe we should stop using the 1 and '1' argument, yes, they can be Maybe not, while there are people that fail to understand it. Here: But try to remember, 1 !== '1' and PHP is not an end all language, often we have to communicate to strictly type systems, we need to be positive So you just ignored the special cases part. Yes, if you have special case where you interface with very brain-dead strictly typed system that absolutely can't understand that '1' and 1 is the same - then you need to _convert_. So how failing when you get '1' instead of 1 helps you? You'd need _conversion_, not _failure_ - and if you write strictly-typed API, you'd move the conversion responsibility to the user, instead of having it where it belongs - in the API. That's *exactly* why I see strict typing in PHP so dangerous - it promotes lazyness and sloppiness in API writing, and those APIs will be a nightmare to use, since they would bomb out on slightest disagreement about internal engine types, which the API user shouldn't care about at all. What happened with be liberal at what you accept? In strict compiled languages, the compiler and IDE will guide you through this, in PHP you'd just have it explode in your face in production. How this is good for anybody? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Fabrice VIGNALS wrote: In mathematic, equal meen the same value AND the same nature. The follow fact could be frustrating : Usually, context is good enough to disambiguate between the cases. The most prevalent convention in programming languages is = is assignment, and == is comparison (PHP adds === only because of its type-juggling system). Other languages have = as comparison, and := as assignment. Donald Knuth uses = as comparison, and a left arrow (-) for assignment. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! Maybe we should stop using the 1 and '1' argument, yes, they can be Maybe not, while there are people that fail to understand it. Here: But try to remember, 1 !== '1' and PHP is not an end all language, often we have to communicate to strictly type systems, we need to be positive So you just ignored the special cases part. Yes, if you have special case where you interface with very brain-dead strictly typed system that absolutely can't understand that '1' and 1 is the same - then you need to _convert_. So how failing when you get '1' instead of 1 helps you? You'd need _conversion_, not _failure_ - and if you write strictly-typed API, you'd move the conversion responsibility to the user, instead of having it where it belongs - in the API. That's *exactly* why I see strict typing in PHP so dangerous - it promotes lazyness and sloppiness in API writing, and those APIs will be a nightmare to use, since they would bomb out on slightest disagreement about internal engine types, which the API user shouldn't care about at all. What happened with be liberal at what you accept? In strict compiled languages, the compiler and IDE will guide you through this, in PHP you'd just have it explode in your face in production. How this is good for anybody? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On 16.06.2008, at 23:02, Stanislav Malyshev wrote: So you just ignored the special cases part. Yes, if you have special case where you interface with very brain-dead strictly typed system that absolutely can't understand that '1' and 1 is the same - then you need to _convert_. So how failing when you get '1' instead of 1 helps you? You'd need _conversion_, not _failure_ - and if you write strictly-typed API, you'd move the conversion responsibility to the user, instead of having it where it belongs - in the API. That's *exactly* why I see strict typing in PHP so dangerous - it promotes lazyness and sloppiness in API writing, and those APIs will be a nightmare to use, since they would bomb out on slightest disagreement about internal engine types, which the API user shouldn't care about at all. What happened with be liberal at what you accept? In strict compiled languages, the compiler and IDE will guide you through this, in PHP you'd just have it explode in your face in production. How this is good for anybody? amen. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Mon, Jun 16, 2008 at 2:02 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! So you just ignored the special cases part. Yes, if you have special case where you interface with very brain-dead strictly typed system that absolutely can't understand that '1' and 1 is the same - then you need to _convert_. So how failing when you get '1' instead of 1 helps you? You'd need _conversion_, not _failure_ - and if you write strictly-typed API, you'd move the conversion responsibility to the user, instead of having it where it belongs - in the API. That's *exactly* why I see strict typing in PHP so dangerous - it promotes lazyness and sloppiness in API writing, and those APIs will be a nightmare to use, since they would bomb out on slightest disagreement about internal engine types, which the API user shouldn't care about at all. What happened with be liberal at what you accept? In strict compiled languages, the compiler and IDE will guide you through this, in PHP you'd just have it explode in your face in production. How this is good for anybody? I get this, really, I do, again. Like the previous post I (likely we) understand. Did you not get or read my post? You say again and again 1 == '1', but you are forgetting those OTHER operators, === and !==. 1 !== '1' does it? Add numeric hinting like I said 50 posts ago and your 1 == '1' problem is solved People who want to make more simple API's will make simple API's offsetting the complexity of your precious 1 '1' to the API level. People who want to make it strictly integer, will continue to do so as they do now. You can not, and should not want to, control the way people program. But I know this will never happen because no one cares what users want... your logic of We should allow user to check for is_int and is_numeric, resource, object, array, string, etc, within any conditional statement under a function or method. Allow checking for object or array in functions or methods paramters. Disallow anything else from being checked in functions or methods paramters. Follow a philosophy that a user should not be concerned with internal data types. Make sure the user has access to internal data types. User should not have to talk to strict typed systems. But if they do have to make it more difficult then it needs to be because it makes more sense, plus those systems are brain dead. How in the world, does this remotely, possibly, even slightly make sense? -Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! I get this, really, I do, again. Like the previous post I (likely we) understand. Unfortunately, it looks like you do not. Probably my failure to explain it clearly. Did you not get or read my post? You say again and again 1 == '1', but you are forgetting those OTHER operators, === and !==. 1 !== '1' does it? Add numeric hinting like I said 50 posts ago and your 1 == '1' I do not talk about the bits in the engine and how all the operators work. I talk about how the user thinks (or should think) about using PHP. Yes, === exists for a reason. But, in most cases == is what you really want, that's why it got to be ==. the API level. People who want to make it strictly integer, will Again, people who want to make it strictly integer are wrong in 90% of the cases. Because of that, giving them more tools to be wrong in 90% of the cases is... well, wrong :) Other 10% are possible, but they do not belong to the language syntax. continue to do so as they do now. You can not, and should not want to, control the way people program. When you design the language, that's what you do, to some measure. You program differently in C, Prolog, LISP, Javascript or PHP. At least, you should - otherwise you are working against the grain of the language and only make yourself work harder then necessary. Of course, you want to give people more tools - but some tools just don't belong there. That's why C[++] has operator* and PHP does not. But I know this will never happen because no one cares what users want... your logic of You seem to confuse what users want with what I want. I don't get all I want from PHP too, and sometimes I think it's wrong. But I also know it is not possible for PHP to satisfy 100% of feature requests from everybody - and even if it were, it would make PHP worse, not better. PHP is in constant process of improvement, so claiming no one cares what users want is just contrary to the facts. How in the world, does this remotely, possibly, even slightly make sense? It doesn't, because you wrote it so on purpose, to misrepresent my position. The position is simple. PHP has certain set of ideas behind it, and certain way of doing things. Having strict hints in function definitions promotes entirely different way of doing things, which fits compiled languages much better and dynamic language like PHP much worse. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi, If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. I like this generally, but cannot live with the BC issues raised. Introducing all type names as keywords will make class Object, class Integer and so on give a syntax error. http://www.google.com/codesearch?q=class+Object+lang%3APHPhl=en - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Sun, 15 Jun 2008, Timm Friebe wrote: If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. I like this generally, but cannot live with the BC issues raised. Introducing all type names as keywords will make class Object, class Integer and so on give a syntax error. http://www.php.net/manual/en/userlandnaming.rules.php regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hello, On Sun, May 25, 2008 at 1:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I see absolutely no use in strict mode. Moreover, I consider it harmful as it teaches people not to use dynamic nature of PHP but instead pepper their code with unnecessary checks and irrelevant errors. As I said, I see no difference that could matter to PHP programmer between '1' and 1, and I don't see why we should encourage making this difference. I know there could be very special cases when it could matter, but importance and frequency of such cases do not warrant, in my opinion, their support by the syntax and the standard library of the language Maybe we should stop using the 1 and '1' argument, yes, they can be juggled to the same thing and I as well as others do see your point man. But try to remember, 1 !== '1' and PHP is not an end all language, often we have to communicate to strictly type systems, we need to be positive of what we send. I.E. XMLRPC Client sends string instead of integer to some merchant API changing the meaning of the request or voiding the transaction. PHP Made a design decision long ago to allow developers to have script types, by this decision with OOP5 and such strict type parameters would be made feature complete and be a additional feature for people to use who want to use it. IMO -Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Sun, 2008-06-15 at 11:44 +0200, Timm Friebe wrote: Hi, If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. I like this generally, but cannot live with the BC issues raised. Introducing all type names as keywords will make class Object, class Integer and so on give a syntax error. That's actually not true, the patch does not introduce new keywords. http://www.google.com/codesearch?q=class+Object+lang%3APHPhl=en - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hello Stanislav,
Thursday, April 17, 2008, 6:57:12 PM, you wrote:
Hi!
So:
function foo($var) { if(!is_int($var)) { throw new exception('not int'); }}
What's the use of such code? If $var is '1' and not 1, what's the use of
as this seems to be your only argument throughout the discussion, I
suggest we implement is_numeric() and alike or allow a second parameter
that to 'is_*($vaue, $strict=true)' that allows to switch to non strict
mocde. We then could easily allow 'numeric' as another type hint. Or in
other words I see this as a completely separate discussion. There are
two discussions:
a) do we want native type hints
b) do we want an easy ability to deal with compatible types in type hinting
marcus
throwing an exception and having to handle it later (basically by
failing the task, since you don't know how to do foo() now) - instead of
just doing with that 1 what was intended for? There's no any difference
between 1 and '1' that can be important to anybody. Only difference is
the way it is represented in underlying bits in zvals, about which
nobody should ever care. That's like making function that would accept
only arguments that has 3'rd bit of pointer set to 1 and 5th bit set to
0, and reject all others. No sane application should ever behave this
way. Writing such function is just plain wrong, it replaces the
substance of programming with nitpicking over the details that are not
important. Whole phenomenon of dynamic languages has grown on the
principle of liberating people from caring for bits and concentrate on
substance, and now you try to drag the bits back in.
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
So every time you call foo you need try/catch? And that's supposed to be
_good_?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! as this seems to be your only argument throughout the discussion, I suggest we implement is_numeric() and alike or allow a second parameter that to 'is_*($vaue, $strict=true)' that allows to switch to non strict mocde. We then could easily allow 'numeric' as another type hint. Or in I see absolutely no use in strict mode. Moreover, I consider it harmful as it teaches people not to use dynamic nature of PHP but instead pepper their code with unnecessary checks and irrelevant errors. As I said, I see no difference that could matter to PHP programmer between '1' and 1, and I don't see why we should encourage making this difference. I know there could be very special cases when it could matter, but importance and frequency of such cases do not warrant, in my opinion, their support by the syntax and the standard library of the language. other words I see this as a completely separate discussion. There are two discussions: a) do we want native type hints b) do we want an easy ability to deal with compatible types in type hinting Just for the record: a) I think the whole idea of type hints, especially with primitive types, goes to a wrong direction - PHP is not a strictly typed language, and shouldn't be. b) However, on practical grounds, since we already have type conversion for internal functions, it won't be too much trouble for a user functions to do the same. On the other hand, making strict types for PHP functions is nothing but trouble, IMO. This is why I think it is not as separate as you think. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! I may be missing something but in this context, string doesn't get very useful (I think), because besides arrays / objects (except Yes, it's not very useful, I agree. However, if you define useful as being able to reject arguments that can be converted to strings but aren't marked as strings, then your definition of useful is radically different from mine, because I don't think PHP programmer needs to do such things (for my nitpicking friends around here, please add unless he's using is_string or serializing or using other one or two very special cases not relevant to this discussion anyway :). 5 marked as integer and 5 marked as string have no useful distinction outside of the context of C engine programming. I also think for many people, including me who favor strict types, also I imagine how hard it was for you to write in PHP or any other dynamic language... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi,
[I'm replying also to Lukas email because of the similarity]
Stanislav Malyshev wrote:
When you can use string but not object with __toString?
my patch does that
Ok, that's great. So then it makes sense to allow converting int-string
too, right? And then it'd also make sense to allow string-int too?
Especially if we have object-int convertor and that can be allowed too.
In fact, we have good old conversion system used in parse_parameters. So
why not use the same rules? That'd make at least some sense - give PHP
programmers the tools that extension C programmers have. I still
wouldn't like it too much but at least it would make sense :)
What would happen to that *type* itself, would it be converted when it gets
into the function, is that what you're proposing?
--
$i = 5;
function foo(string $s) {
// $s implicitely gets 5 ?
}
foo($i);
--
I may be missing something but in this context, string doesn't get very
useful (I think), because besides arrays / objects (except __toString),
everything can be converted to a string, it isn't type hinting anymore but
type converting.
What about I/O parameters?
--
$i = 5;
function foo(string $s) {
// $s implicitely gets 5 ?
}
foo($i);
// $i is now 5 ?
--
I think that's a major wtf factor.
I also think for many people, including me who favor strict types, also see it
as a helpful protection mechanism. During development it happens regularly
that I mix up parameters, but still my code continues execution.
Sometimes this can be fatal, wrong variable wrong value wrong place and
suddenly I've values at certain code points I wouldn't have expected them
there. user id instead of a name there, etc.
Or when somewhere an external input leaks down into the code with a wrong
type/value because it isn't checked anyway, suddenly a catchable fatal error
is thrown and the application is (can be ...) automatically protected by not
further executing it.
sincerely,
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Lukas Kahwe Smith wrote: Suddenly I need to ensure that all my variables have the proper types. So what will people do? They will start forcing type juggeling manually before they call the library in question. Since this is the glue code, its the kind of code you have to write day in day out. So maybe an (int) here or there is not so much more code to type, but you can already see that code you safe on one end, you have to start adding on the other, the one which you write more often. More importantly, in some cases simple type juggeling with (int) will not be sufficient, you might have to do some minor checks etc. In the past library authors did this as part of the code that the strict type hinting camp is now hoping to remove. So again more code in my glue code. You're absolutely right about that glue code. However, I think this serves as a benefit for the developers using the library/framework/component/whatever. It reduces the chances of passing wrong types around, he's forced to grapple with the parameter in a proper way and would, ahead of executing code with possible wrong values, have a change to correct it. Yes, the code can likely look like $foo-bar( (int)$baz, (string)$sober, (bool)$result['column_checkbox'] ); but this means he is really forced to think what he is really passing. It will not raise the overall code quality in a major way, but it helps developers on both sides (devs of libraries, devs of using the libraries) to ensure proper passing of varaibles. It is optional. And it will likely be only used by library/framework/component/whatever. But for them, I think, it's a win. sincerely, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Felipe, Am Donnerstag, den 17.04.2008, 21:24 -0300 schrieb Felipe Pena: [...] But i think that istype as name is confuse in this case. We need a name for that. isOfType(), just is() or isA() (and than also allowing classnames) or maybe getType(), similiar to the currently existing getClass(). getType() would return the type as a string, so one could do $reflected-getType() == 'string'. Anyway, just thinking loud ... cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hello All, I just want to bring in a different perception on the proposed feature. I think people are very focused on what I call library code. This is the kind of code that should in theory be worked on less, than the glue code that you write in every project to finish up the applications your customers have requested. IMHO type hinting and more importantly strict type hinting is very focused with making the life of library developers easier. They can just easily discard anything that doesnt match their expectations 100%. That this is not how PHP has traditionally worked has been mentioned quite often in this thread. But I want to direct peoples attention to the code that calls strictly typed libraries. Suddenly I need to ensure that all my variables have the proper types. So what will people do? They will start forcing type juggeling manually before they call the library in question. Since this is the glue code, its the kind of code you have to write day in day out. So maybe an (int) here or there is not so much more code to type, but you can already see that code you safe on one end, you have to start adding on the other, the one which you write more often. More importantly, in some cases simple type juggeling with (int) will not be sufficient, you might have to do some minor checks etc. In the past library authors did this as part of the code that the strict type hinting camp is now hoping to remove. So again more code in my glue code. Furthermore people over estimate the usefulness of automated errors. They tend to include very minimal context information. So when in the past people had to write out the parameter checking code manually, they had the opportunity to very easily add important context information to whatever error they raised. This will no longer be the case with strict type hinting. There it will be the responsibility for the caller to make sense of the error and know whatever context is relevant for this error condition. I guess the reply I can expect from this mail is that I do not have to use it, that I do not have to use libraries that use strict type hinting or that good developers will pick and choose when to use strict type hinting. While this may be true, we do not live in a perfect world. So again I want to remind people that as we develop the language, we need to pick and choose what features come in that will ensure that PHP remains at least as productive has it has been in the past for its users. As such I want to again bring up that a loose type hinting with types like scalar and numeric are much less risky, since they are a much wider filter. Its quite easy to figure out why a function that is documented to not operate on arrays to come back with an error when I pass it an array. However it will be a bit confusing to get an error when I pass '1' to a method that then comes back to complain I did not pass an integer. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
2008/4/18, Lukas Kahwe Smith [EMAIL PROTECTED]: Hello All, I just want to bring in a different perception on the proposed feature. I think people are very focused on what I call library code. This is the kind of code that should in theory be worked on less, than the glue code that you write in every project to finish up the applications your customers have requested. IMHO type hinting and more importantly strict type hinting is very focused with making the life of library developers easier. They can just easily discard anything that doesnt match their expectations 100%. That this is not how PHP has traditionally worked has been mentioned quite often in this thread. But I want to direct peoples attention to the code that calls strictly typed libraries. Suddenly I need to ensure that all my variables have the proper types. So what will people do? They will start forcing type juggeling manually before they call the library in question. Since this is the glue code, its the kind of code you have to write day in day out. So maybe an (int) here or there is not so much more code to type, but you can already see that code you safe on one end, you have to start adding on the other, the one which you write more often. More importantly, in some cases simple type juggeling with (int) will not be sufficient, you might have to do some minor checks etc. In the past library authors did this as part of the code that the strict type hinting camp is now hoping to remove. So again more code in my glue code. Furthermore people over estimate the usefulness of automated errors. They tend to include very minimal context information. So when in the past people had to write out the parameter checking code manually, they had the opportunity to very easily add important context information to whatever error they raised. This will no longer be the case with strict type hinting. There it will be the responsibility for the caller to make sense of the error and know whatever context is relevant for this error condition. I guess the reply I can expect from this mail is that I do not have to use it, that I do not have to use libraries that use strict type hinting or that good developers will pick and choose when to use strict type hinting. While this may be true, we do not live in a perfect world. So again I want to remind people that as we develop the language, we need to pick and choose what features come in that will ensure that PHP remains at least as productive has it has been in the past for its users. As such I want to again bring up that a loose type hinting with types like scalar and numeric are much less risky, since they are a much wider filter. Its quite easy to figure out why a function that is documented to not operate on arrays to come back with an error when I pass it an array. However it will be a bit confusing to get an error when I pass '1' to a method that then comes back to complain I did not pass an integer. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think that this functionality can work for numeric types like this: if we have one of the numeric types hinted for function arg then we need to check if it is_numeric and if it is - we can convert it. If we have a string witch can't be converted to regular numeric type without loosing information (strings like 45s, asdf32325 etc) - rase a recoverable error (or exception - that way user can catch it and display it's own error text or do some actions about it). That way I think we won't lose the flexebility of PHP's dynamic type conversions but we will make it a little bit more strict on what we are passing to function (realy, if it is possible that string will be passed to function where you have to have integer - don't you check it anyway for correct type and value? Mostly on that check result is an error triger_error/exit/die/etc.).
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Fri, Apr 18, 2008 at 9:03 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Suddenly I need to ensure that all my variables have the proper types. So what will people do? So maybe an (int) here or there is not so much more code to type, but you can already see that code you safe on one end, you have to start adding on the other, the one which you write more often. You are right, of course. I stated before that the hints automatically casting the parameter is the best approach. With automatic casting, which seems to be fairly obvious semantics for type hints, you will not need to cast at call-time. More importantly, in some cases simple type juggeling with (int) will not be sufficient, you might have to do some minor checks etc. In the past library authors did this as part of the code that the strict type hinting camp is now hoping to remove. So again more code in my glue code. There isn't a strict typing camp. Felipe's first patch was just checking, which didn't provide any guarantees to the library author. The second was strict typing, which provides guarantees, as you say, at great expense. I am hoping that the third will be casting, which provides guarantees, at no call-time expense. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Felipe, Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Em Qui, 2008-04-17 às 17:17 +0200, Paul Biggar escreveu: Hi Felipe, Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? I added yesterday an information about that in the doc: Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call. Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 5:24 PM, Felipe Pena [EMAIL PROTECTED] wrote: Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. Ah, I should have been more specific. I meant to ask for those changes. Can I ask why not? I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? I added yesterday an information about that in the doc: Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call. That doesnt explain why its allowed. Can you elaborate? Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena. -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
In this case, I'd suggest using my patch for parameter type hinting. It utilizes the current type hinting system for minimal code changes, whereas this is a whole new set of functionality. It also has scalar and number types, and supports objects with __tostring methods. On Thu, 2008-04-17 at 11:42 -0300, Felipe Pena wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 17:29 +0200, Paul Biggar wrote: On Thu, Apr 17, 2008 at 5:24 PM, Felipe Pena [EMAIL PROTECTED] wrote: Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. Ah, I should have been more specific. I meant to ask for those changes. Can I ask why not? I think scalar is very important. For any function where you are interacting with the database values or echoing output, scalar is very useful. I also wonder about allowing NULL for an 'array' type hint. Is this acceptable? The patch seems to indicate it is. If so, why is this allowed? I added yesterday an information about that in the doc: Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call. That doesnt explain why its allowed. Can you elaborate? The way i do it is to only allow null if null is the default. This way, people cannot skip parameters using null unless specifically allowed to in the function declaration. Thanks, Paul On Thu, Apr 17, 2008 at 4:42 PM, Felipe Pena [EMAIL PROTECTED] wrote: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Examples, patches and tests: http://wiki.php.net/rfc/typehint -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena. -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! If anyone wants use type hinting, i believe that it should be strict. Otherwise, it makes more sense to not use it. Just for the record, I see absolutely no sense in strict type hints. While there might be some use cases when you want to save typing by having function convert the arguments instead of you doing it manually - there's absolutely no sense to check types strictly in PHP, especially taking into attention that no API ever worked that way, and that it would force users to surround each call to such function with checks for argument types, since PHP can not have static type control. Using such feature would be a nightmare. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:33 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Just for the record, I see absolutely no sense in strict type hints. While
there might be some use cases when you want to save typing by having
function convert the arguments instead of you doing it manually - there's
absolutely no sense to check types strictly in PHP, especially taking into
attention that no API ever worked that way, and that it would force users to
surround each call to such function with checks for argument types, since
PHP can not have static type control. Using such feature would be a
nightmare.
You have a good point, but I think it might have slightly more benefit then
we may think. Less code bloat for the checks many of us already enforce is
one.
Doing some greps in the Zend Framework is a good example.
grep -riE -A2
is_(binary|bool|double|float|int|long|null|numeric|object|real|resource|scalar|string|unicode)
*
I get tons of parameter checks which throw exceptions, so users already have
to check there code prior to sending it up the chain. And by Check a good
framework, like Zend, will do the boundary checking for you, so as long as
it is the right type you are ok.
So:
function foo($var) { if(!is_int($var)) { throw new exception('not int'); }}
Turns to:
function foo(int $bar) { }
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
-Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi!
So:
function foo($var) { if(!is_int($var)) { throw new exception('not int'); }}
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by
failing the task, since you don't know how to do foo() now) - instead of
just doing with that 1 what was intended for? There's no any difference
between 1 and '1' that can be important to anybody. Only difference is
the way it is represented in underlying bits in zvals, about which
nobody should ever care. That's like making function that would accept
only arguments that has 3'rd bit of pointer set to 1 and 5th bit set to
0, and reject all others. No sane application should ever behave this
way. Writing such function is just plain wrong, it replaces the
substance of programming with nitpicking over the details that are not
important. Whole phenomenon of dynamic languages has grown on the
principle of liberating people from caring for bits and concentrate on
substance, and now you try to drag the bits back in.
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
So every time you call foo you need try/catch? And that's supposed to be
_good_?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the task, since you don't know how to do foo() now) - instead of just doing
with that 1 what was intended for? There's no any difference between 1 and
'1' that can be important to anybody. Only difference is the way it is
represented in underlying bits in zvals, about which nobody should ever
care. That's like making function that would accept only arguments that has
3'rd bit of pointer set to 1 and 5th bit set to 0, and reject all others. No
sane application should ever behave this way. Writing such function is just
plain wrong, it replaces the substance of programming with nitpicking over
the details that are not important. Whole phenomenon of dynamic languages
has grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
So every time you call foo you need try/catch? And that's supposed to be
_good_?
Somebody missed the point...
Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used int instead of numeric, but my
point is the same, grep in zend framework for is_bool.
It does what you are complaining about:
From: Zend_Pdf_Element_Numeric
public function __construct($val)
{
if ( !is_numeric($val) ) {
throw new Zend_Pdf_Exception('Argument must be numeric');
}
$this-value = $val;
}
That could be...
public function __construct(numeric $val)
{
$this-value = $val;
}
So, let's re-visit my point of less code bloat
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 10:06 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 9:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the task, since you don't know how to do foo() now) - instead of just doing
with that 1 what was intended for? There's no any difference between 1 and
'1' that can be important to anybody. Only difference is the way it is
represented in underlying bits in zvals, about which nobody should ever
care. That's like making function that would accept only arguments that has
3'rd bit of pointer set to 1 and 5th bit set to 0, and reject all others. No
sane application should ever behave this way. Writing such function is just
plain wrong, it replaces the substance of programming with nitpicking over
the details that are not important. Whole phenomenon of dynamic languages
has grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
So every time you call foo you need try/catch? And that's supposed to be
_good_?
Somebody missed the point...
Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used int instead of numeric, but my
point is the same, grep in zend framework for is_bool.
It does what you are complaining about:
From: Zend_Pdf_Element_Numeric
public function __construct($val)
{
if ( !is_numeric($val) ) {
throw new Zend_Pdf_Exception('Argument must be numeric');
}
$this-value = $val;
}
That could be...
public function __construct(numeric $val)
{
$this-value = $val;
}
So, let's re-visit my point of less code bloat
Actually, is_numeric checks for strings that contain numeric values,
it's not the same as is_bool, is_int, is_float, etc, which check the
variable's type.
Your point is very valid for is_int and similar functions, just not
is_numeric(). I just did a grep on zend framework for is_int and there
were tons of results.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:11 AM, Sam Barrow [EMAIL PROTECTED] wrote: Actually, is_numeric checks for strings that contain numeric values, it's not the same as is_bool, is_int, is_float, etc, which check the variable's type. Hence my second example = ) Your point is very valid for is_int and similar functions, just not is_numeric(). I just did a grep on zend framework for is_int and there were tons of results. I think it is valid for anything, numeric type hinting is very appropriate in php.
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 10:23 -0700, Chris Stockton wrote: On Thu, Apr 17, 2008 at 10:11 AM, Sam Barrow [EMAIL PROTECTED] wrote: Actually, is_numeric checks for strings that contain numeric values, it's not the same as is_bool, is_int, is_float, etc, which check the variable's type. Hence my second example = ) Your point is very valid for is_int and similar functions, just not is_numeric(). I just did a grep on zend framework for is_int and there were tons of results. I think it is valid for anything, numeric type hinting is very appropriate in php. Numeric type hinting is valid, all I'm saying is that PHP's is_numeric function doesn't perform a strict type check like is_int or is_bool. I agree with you I just think you misunderstood the purpose of the is_numeric function. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 17 Apr 2008, Felipe Pena wrote: Em Qui, 2008-04-17 às 17:17 +0200, Paul Biggar escreveu: Hi Felipe, Thanks for making the change. This is much more consistent. It remains that there is no 'scalar' or 'numeric' hint. Are you planning on including them? No, i'm not planning to do that. I don't think scalar is very useful, but I do think there is a case for numeric. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Derick Rethans wrote: I don't think scalar is very useful, but I do think there is a case for numeric. I don't think string is useful. I would use scalar instead. I only need to know that the variable is not an array or object. I can echo, concatenate, etc. any scalar as if it was a string. -- Brian Moon Senior Developer/Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
I just did a grep on zend framework for is_int and there were tons of results. No offense to Zend, I love thos guys, but I don't think using Zend Framework as the gold standard for how people want to code in PHP is the right thing to do. -- Brian Moon Senior Developer/Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! Seeing how you work for zend I thought maybe you have used the zend framework = ) Sorry in my example I used int instead of numeric, but my point is the same, grep in zend framework for is_bool. It might come as a surprise to you, but I did not write whole Zend Framework personally :) Moreover, as even more surprise I did not even inspect personally each line of code. As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). Even if they can't, it's much better to be handled on user code level with error message that makes sense and way that makes sense for application - but I could kind of live with the scenario where these hints would work as internal function types work now. However, that's not what is proposed - what is proposed is that if you've got int typehint, '1' would be rejected. Having such restriction makes no sense and goes contrary to what PHP and dynamic languages in general are. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Stanislav, On Thu, Apr 17, 2008 at 7:59 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). This is of course why I suggested that the best approach would be automatically convert them, rather than reject a type which can be coerced appropriately. I would settle for the current proposal, but if you're going to make the language weakly-typed, which it is, it is more appropriate to keep this in line with the rest of the language. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:59 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! Seeing how you work for zend I thought maybe you have used the zend framework = ) Sorry in my example I used int instead of numeric, but my point is the same, grep in zend framework for is_bool. It might come as a surprise to you, but I did not write whole Zend Framework personally :) Moreover, as even more surprise I did not even inspect personally each line of code. As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). Even if they can't, it's much better to be handled on user code level with error message that makes sense and way that makes sense for application - but I could kind of live with the scenario where these hints would work as internal function types work now. However, that's not what is proposed - what is proposed is that if you've got int typehint, '1' would be rejected. Having such restriction makes no sense and goes contrary to what PHP and dynamic languages in general are. That first part made me laugh, hehe. I wanted to just point out that your company was a good example of how code could be minimized using type checks. I understand your philosophy with dynamic types in php, but there are times that these dynamic types have really shot people in the foot and added exploits and bad coding practices, which is why high-quality frameworks push users to use correct types, zf is just one of many examples my friend. I get your point of 12 and '12', which is why I proposed earlier numeric hinting would be very appropriate. -Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
I like and will use it a lot... sometimes you simple cannot trust on php
dynamic type convertion, please see the following example
?php
function check_user($user_id) {
if ($user_id == 0) {
// root user
} else if ($user_id 0 $user_id 1000) {
// special admin users
} else {
// standard users
}
}
?
Now if someone thinks $user_id is the user login name and call
check_user('login_name');
'login_name' will be converted to 0 (zero) as per php automatic string
to numeric convertion and this user will be handled as being the root
user. In this case strict comparison === is not apropriate, and I'm
forced to verify the parameter against is_numeric.
I much simpler approach would be...
?php
function check_user(int $user_id) {...}
Also I think this is a basic prerequisite to allowing function overload
on php OO side in the future ;)
Thanks,
Jaris.
Stanislav Malyshev wrote:
Hi!
So:
function foo($var) { if(!is_int($var)) { throw new exception('not
int'); }}
What's the use of such code? If $var is '1' and not 1, what's the use
of throwing an exception and having to handle it later (basically by
failing the task, since you don't know how to do foo() now) - instead
of just doing with that 1 what was intended for? There's no any
difference between 1 and '1' that can be important to anybody. Only
difference is the way it is represented in underlying bits in zvals,
about which nobody should ever care. That's like making function that
would accept only arguments that has 3'rd bit of pointer set to 1 and
5th bit set to 0, and reject all others. No sane application should
ever behave this way. Writing such function is just plain wrong, it
replaces the substance of programming with nitpicking over the details
that are not important. Whole phenomenon of dynamic languages has
grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
So every time you call foo you need try/catch? And that's supposed to
be _good_?
--
*Jarismar Chaves da Silva, M.Sc.*
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! Scalar is useful if you DON'T want an array or object - but don't care if you get an int/string/whatnot When you can use string but not object with __toString? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, 2008-04-17 at 11:43 -0700, Stanislav Malyshev wrote: Hi! Scalar is useful if you DON'T want an array or object - but don't care if you get an int/string/whatnot When you can use string but not object with __toString? my patch does that -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi! When you can use string but not object with __toString? my patch does that Ok, that's great. So then it makes sense to allow converting int-string too, right? And then it'd also make sense to allow string-int too? Especially if we have object-int convertor and that can be allowed too. In fact, we have good old conversion system used in parse_parameters. So why not use the same rules? That'd make at least some sense - give PHP programmers the tools that extension C programmers have. I still wouldn't like it too much but at least it would make sense :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:04 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: In fact, we have good old conversion system used in parse_parameters. So why not use the same rules? That'd make at least some sense - give PHP programmers the tools that extension C programmers have. I still wouldn't like it too much but at least it would make sense :) As I read it, these convert the parameter to the expected type, if it is not already, and fail when this is not possible. All thats missing is scalar and numeric to be consistent with the is_*(), and its perfect. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hi Felipe, first of all, thanks for your proposal. I like it. Am Donnerstag, den 17.04.2008, 11:42 -0300 schrieb Felipe Pena: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. [...] I would also like to see scalar and numeric too, but that's just for the record. For ReflectionParameter I would like to see an additional ReflectionParameter::isType(string $type_name) to allow constructs like foreach (array(string, integer) as $type) if (!$reflection_param-isType($type)) throw new Exception(); What about additions in the ReflectionMethod-class? I would say adding ReflectionMethod::isInt(), ...::isDouble() and isType() would be appropriate. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Em Qui, 2008-04-17 às 23:14 +0200, Lars Strojny escreveu: Hi Felipe, first of all, thanks for your proposal. I like it. Am Donnerstag, den 17.04.2008, 11:42 -0300 schrieb Felipe Pena: Hi. Well, thinking better about the behavior of type hinting, i decided to change the proposal for strict type. I.e. don't accept numeric string as an intenger, etc. [...] I would also like to see scalar and numeric too, but that's just for the record. For ReflectionParameter I would like to see an additional ReflectionParameter::isType(string $type_name) to allow constructs like foreach (array(string, integer) as $type) if (!$reflection_param-isType($type)) throw new Exception(); I also thought that when adding the istype methods! :D What about additions in the ReflectionMethod-class? I would say adding ReflectionMethod::isInt(), ...::isDouble() and isType() would be appropriate. Sure, should there be! Thanks for remember me. But i think that istype as name is confuse in this case. We need a name for that. -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
