Page 3 of 5
Re: How do you feel about type-hinting
Posted: Wed Jun 17, 2009 10:12 pm
by alex.barylski
Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
Now i know the code is secure, at least in the sense that when I use the PKID to lookup some file in a path construction like:
templates/somredir/layouts/$pkid/index.tpl
Whereas if I didn't cast it might be possible for an attacker to re-construct the path by passing something like:
index.php?pkid=../../../some/secretpath/
Re: How do you feel about type-hinting
Posted: Wed Jun 17, 2009 10:20 pm
by jgadrow
It's about coding a contract that client code must adhere to.
Yes, you can cast at initialization. However, I frequently write code that must (at some later date) be used by OTHER programmers down the line. I need to make sure that they don't silently break the system by trying to send some funky variable that the function (or method as is usually the case) never expected. Since I never know exactly WHO is calling the code, I can't exactly trust them to always have their data correct. This is why I validate the data I receive in the function.
Now, by allowing type-hinting for objects and arrays, they've basically allowed me the same ability as 'casting' a variable upon initialization. I can ensure that the information I receive will either be proper, or will throw an error that will need to be handled by the client code. However, since they only allow it for arrays and objects, I'm still left manually verifying the other variable types.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 12:18 am
by Benjamin
PCSpectra wrote:Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
This is a common approach, however I disagree with it. The reason I disagree with it is because rather than verifying that the data is what was expected, you force it to be something you expect. This can only lead to unexpected behaviour or
unusual bugs. I would definitely discourage this practice.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 6:51 am
by Jenk
jgadrow wrote:It's about coding a contract that client code must adhere to.
Yes, you can cast at initialization. However, I frequently write code that must (at some later date) be used by OTHER programmers down the line. I need to make sure that they don't silently break the system by trying to send some funky variable that the function (or method as is usually the case) never expected. Since I never know exactly WHO is calling the code, I can't exactly trust them to always have their data correct. This is why I validate the data I receive in the function.
Now, by allowing type-hinting for objects and arrays, they've basically allowed me the same ability as 'casting' a variable upon initialization. I can ensure that the information I receive will either be proper, or will throw an error that will need to be handled by the client code. However, since they only allow it for arrays and objects, I'm still left manually verifying the other variable types.
Sorry, but that's bull. It's not about "creating a contract" (again with this inappropriate jargon) it's about
restricting future development and possible uses. I'm betting the 'reasons' listed for using type-hinting have never, ever been an issue before type-hinting was introduced, but tick a "that
could be nice" box instead.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 11:47 am
by alex.barylski
This is a common approach, however I disagree with it. The reason I disagree with it is because rather than verifying that the data is what was expected, you force it to be something you expect.
Casting is only one or several stages of sanitizing/security checks that I exeucte, I still:
All incoming data at various stages of execution.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 12:23 pm
by jgadrow
Jenk wrote:Sorry, but that's bull. It's not about "creating a contract" (again with this inappropriate jargon) it's about restricting future development and possible uses. I'm betting the 'reasons' listed for using type-hinting have never, ever been an issue before type-hinting was introduced, but tick a "that could be nice" box instead.
Prior to the availability of type-hinting, I had to manually verify ALL incoming function data. I started using PHP after first being grounded in a 'typed' language. I don't know how simply validating the type of your incoming data is 'restricting future development' it can always be changed, if necessary, in the next version. However, simply running your code without bothering to know what data was sent to your function is a VERY good way to introduce logic errors.
Type hinting allows the definition of an interface that can say right in the function argument list, "Hey! If you send me something other than an A object instance you're going to break me!"
Do you also leave your SQL statements un-validated and un-escaped because you're preventing the user from a 'possible use' of, say, outputting or deleting all of your database table? There MUST be limitations or you introduce possible system ABUSES.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 12:44 pm
by Jenk
jgadrow wrote:Jenk wrote:Sorry, but that's bull. It's not about "creating a contract" (again with this inappropriate jargon) it's about restricting future development and possible uses. I'm betting the 'reasons' listed for using type-hinting have never, ever been an issue before type-hinting was introduced, but tick a "that could be nice" box instead.
Prior to the availability of type-hinting, I had to manually verify ALL incoming function data. I started using PHP after first being grounded in a 'typed' language. I don't know how simply validating the type of your incoming data is 'restricting future development' it can always be changed, if necessary, in the next version. However, simply running your code without bothering to know what data was sent to your function is a VERY good way to introduce logic errors.
No. You might think it does, but type verifying every incoming parameter is nothing but paranoia. I'm yet to see any proof for it being problematic to not have type restrictions. The difference between it breaking because of no interface, compared to not answering to a method is nil. Your tests will capture any misaligned behaviour. You've also provided the perfect point to my argument. You are using them because you have only ever used them. You've never even tried not using them, so you have no basis for an argument.
Type hinting allows the definition of an interface that can say right in the function argument list, "Hey! If you send me something other than an A object instance you're going to break me!"
Whilst at the same time saying "Hey, I'm going to break if you are not implementing this arbitrary interface, even if you actually do answer to my demands."
Do you also leave your SQL statements un-validated and un-escaped because you're preventing the user from a 'possible use' of, say, outputting or deleting all of your database table? There MUST be limitations or you introduce possible system ABUSES.
That's is quite frankly a laughable comparison.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 3:02 pm
by DrTom
Design by contract is a fundamental principle that has been written about 1000s of times and in many instances makes a lot of sense. As far as PHP goes, it actually makes a lot of sense. Being as how theres no way to give a recoverable error if the wrong type of object were passed in without manually testing that methods were available that you expected to be on every object. In languages like python, where that raises an exception and not a fatal error, thats a different story.
Also, the C# example is kind of irrelevant since C# is NOT a duck typed language and it isn't for a reason. The compiler can make lots of optimizations based on typed methods rather than figuring those things out at run time. Proper use of types / interfaces can also drastically reduce build time in compiled languages which is hugely important when doing test driven development. However, it is rather stupid that people type hint for final classes, but in all cases I've ever seen this, it's trivial to work around this.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 4:31 pm
by kaisellgren
PCSpectra wrote:Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
Let's say we have a method of a class which takes an integer parameter. If you throw an exception due to a non-integer parameter, then another developer will actually become notified and will realize that he supplied an improper value. In case of type casting, everything would happen silently and that might cause unexpectable bugs.
Re: How do you feel about type-hinting
Posted: Thu Jun 18, 2009 9:27 pm
by Jenk
kaisellgren wrote:PCSpectra wrote:Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
Let's say we have a method of a class which takes an integer parameter. If you throw an exception due to a non-integer parameter, then another developer will actually become notified and will realize that he supplied an improper value. In case of type casting, everything would happen silently and that might cause unexpectable bugs.
But that developers tests will highlight incorrect behaviour, so there really is no need for any form of hint/cast/check

Re: How do you feel about type-hinting
Posted: Sat Jun 27, 2009 8:38 pm
by Minty
I agree to some degree with Jenk on this, however your view relies far to much on developers knowing what they are doing
Calling type hinting, scope restricting (private/public etc) et al 'paranoid' is true to a degree but it is for the sake of future developers
easily finding out if/where they've gone wrong. In an ideal world all developers would use comprehensive testing to ensure things were working as they should however that is not a world we live in.
Most if not all of the problems you describe could also be avoided by making considered and appropriate use of the features, type-hinting final classes, privatising all a classes members etc is bad practice, however type-hinting for interfaces and protecting a classes 'internal' members can be very useful as a self documenting feature and debugging tool.
On balance these are functionalities that can be more good than harm, and I wouldn't not implement something beneficial just because some people choose to use them foolishly
As a note: I use public and protected scope limiters in my code but do not use type-hinting, however I see it useful for frameworks etc passing lots of objects around.
Re: How do you feel about type-hinting
Posted: Sat Jun 27, 2009 11:23 pm
by Jenk
I agree that we agree in places
However, Developer foolishness/naivity/inexperience will, in my experience at least, lead them to implementing a concrete class as they will not be aware of the implications. Simply put, they'll not have the broad vision to see past their own objective to consider the consequences of using private/final, and will have the .. I don't quite know how to describe it .. to say "don't use this in anyway but the way I want it used, so why should I bother using an Interface if it's only ever going to use my class?" Ya-know.. The type of developer that will actually promote their work as "completely hand written from scratch" as a
plus side.
Re: How do you feel about type-hinting
Posted: Sun Jun 28, 2009 6:23 am
by kaisellgren
Jenk wrote:But that developers tests will highlight incorrect behaviour, so there really is no need for any form of hint/cast/check

I know. The point is, maybe that applies to you, but no all developers test well and most developers I have seen test for bugs manually by using the software which will miss a load of unexpected things. The reason why I wouldn't using Public properties for non-public properties is not just the fact that it makes sense but also the fact that leaving it public assumes the developer will catch all bugs. I want to avoid that. I want to avoid bugs at all costs. Both software bugs and real life ones drive me nuts.

Re: How do you feel about type-hinting
Posted: Sun Jun 28, 2009 3:17 pm
by Christopher
I really have to agree with Jenk here. And I hate to admit that because I love to argue with Jenk!
But when I read things like
"Prior to the availability of type-hinting, I had to manually verify ALL incoming function data" where the person is really saying
"I had to do something I did not have to do and PHP made be do it." Or obviously erroneous statements like
"theres no way to give a recoverable error if the wrong type of object were passed in without manually testing that methods were available" which seems to propose that wrapping method calls in try/catch is superior somehow to doing normal logic checks when necessary (which is infrequent).
This is not a conversation about whether there is a way to do what you want to do in PHP. It is about people not liking the way PHP solves problems. The comments are generally anti-scripting. There has always been a lot of resistance to PHP's "worse is better" approach. I think it was Larry Wall who said that "PHP takes 'worse is better' to new lows" which if you don't understand it was a compliment.
I honestly think people misunderstand PHP. I will go further and make the outrageous statement that people now forced to use PHP because PHP is a better solution than a language they love, are now trying to give PHP many of the features that caused those languages to be a worse solution.
Re: How do you feel about type-hinting
Posted: Tue Jun 30, 2009 4:01 am
by Popcorn
bit philosophical but ...
the OP said:
When I came to the realization what had happened (like all errors) I sit down and try and discover the true root of the problem and employ practices which prevent that from ever happening again (if I wasn't so diligent in testing that error may not have been discovered for quite some time).
the true root of a problem is not typing of any sort. it's when we do/pass the wrong thing. it seems everything after that to try and prevent errors (and there's a lot, including fixing errors you'll make doing it) had better be worth it.
controlling stuff is not a bad idea (buffer overflows anyone?), i just reckon you have to think hard about the real frequency and cost of the errors you make. there's a lot of attraction to being safe but don't let it become an attraction to the 'appearance of safety' for massive cost.