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