On Tue, 2008-02-05 at 23:19 +0000, Richard Quadling wrote: > On 05/02/2008, Tomi Kaistila <[EMAIL PROTECTED]> wrote: > > > No one seems to have answered my point that actually relying on type > > > juggling for anything other than string concatenation is asking for a > > > problem. > > Probably because there isn't a way to answer that point. Anyone who does > > would > > be laughed out of the barn. Like I told Sam just few minutes ago, the fact > > is > > that no matter how wonderful PHP's juggling is, there is still a reason why > > we have different data types. If it was all the same we wouldn't need > > integer, float, et cetera. But we do have them and we do need them. > > I think I've failed to be understood. > > If you are internally processing say a float, you will use a float in > the format of $float = 3.1415; sort of thing, not $float = "3.1415"; > (which is valid but different). > > > We are all told that user input data is dangerous. So we protect > ourselves by filtering in some way. One way is to cast variables to > their correct type. > > My point is that once you are working on scalar data internally, the > type rarely changes. Type juggling is not actually used. With the > exception of string concatenation, automatic type juggling doesn't > seem to be used. > > So, having an interface into a library which says I need that > parameter as an integer and having php enforce it, sounds like a > winner to me. I write less type checking code. >
Yes, but I think we have to face facts that this will not be implemented. I have come to understand the opposing argument. If PHP does do type juggling, we should try to stick to that model. A scalar type hint works in exactly the same way as the array type hint, without any incompatibilities due to type juggling confusion. This way we can all be happy, as the patch sticks to the current PHP philosophies. > > The whole objection against this feature was never about the technical > > merits > > of it. It was just simply about some people saying "I don't like it" and > > thus > > concluding that it should not be added. > > > > > > Tomi Kaistila > > PHP Developer > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
