Page 1 of 2
Typed or not-typed data?
Posted: Wed Sep 14, 2005 7:49 am
by timvw
- Well, PHP5 is out for a year, and so is typehinting for function parameters. Is it really an advantage that you can typehint a function/method parameter or is it somewhat useless in our (loosely typed/typeless) PHP?
- How do you feel about the existence of is_* functions and == vs === in PHP?
- In general, what are the (dis)advantages of typed data in PHP?
Re: Typed or not-typed data?
Posted: Wed Sep 14, 2005 11:33 am
by feyd
timvw wrote:- Well, PHP5 is out for a year, and so is typehinting for function parameters. Is it really an advantage that you can typehint a function/method parameter or is it somewhat useless in our (loosely typed/typeless) PHP?
To force proper usage, we're using typehinting in several places. It helps to better enforce proper usage of the hierarchy for us.. We also wrote a whole lot of stuff to do strict type checking because we're getting so annoyed with the extremely loose nature of typeless..
timvw wrote:- How do you feel about the existence of is_* functions and == vs === in PHP?
I love and use both, heavily.
timvw wrote:- In general, what are the (dis)advantages of typed data in PHP?
so long as there is explicit and implicit conversions of base types, along with accurate handling of inheritance mapping, I love it.
Posted: Wed Sep 14, 2005 2:40 pm
by andre_c
I use type hinting all the time too. I wish they had included built-in types.
can't really think of a disadvantage
Posted: Wed Sep 14, 2005 4:25 pm
by McGruff
I wish they hadn't done it. I don't see much need for it in a dynamic language. If you're testing, you'll soon find out if something's wrong.
Except.. I'm not using
DependencyInjection and it could be useful for that.
Posted: Wed Sep 21, 2005 11:54 am
by BDKR
McGruff wrote:
I wish they hadn't done it. I don't see much need for it in a dynamic language. If you're testing, you'll soon find out if something's wrong.
I tend to agree, but it is nice in libraries that I wrote that passed objects are indeed objects instantiated from the correct class.
Posted: Wed Sep 21, 2005 11:55 am
by feyd
the nice part is you don't have to use typehinting if you don't want to

Posted: Wed Sep 21, 2005 12:04 pm
by andre_c
i also like that it serves for quick documentation when looking at methods
Posted: Wed Sep 21, 2005 12:29 pm
by McGruff
feyd wrote:the nice part is you don't have to use typehinting if you don't want to

I wish that were true. I just know I'm going to end up tripping over it in a library sometime with a perfectly good class - which might have been able to accept a whole range of objects - hamstrung by hints. It makes it harder to adapt and extend. Polymorphism is central to the flexibility of OOP code.
I've only once genuinely had to enforce class type in some code for setting up a sandboxed test area: it absolutely has to use a special kind of database object which outwardly presents the same interface as the standard version but internally does some query authorisation to block queries which attempt to manipulate live data. A quick get_class check did the trick. The rest of the time, unit tests would pretty quickly let me know if something was going wrong.
People sometimes say the best code is made simple as possible until nothing can be taken away. Hints look like a lot of unecessary baggage in a language like php - I'll keep an open mind though.
Posted: Wed Sep 21, 2005 12:32 pm
by McGruff
andre_c wrote:i also like that it serves for quick documentation when looking at methods
I'm looking for stronger arguments (dependency injection might be one). The thing is a hint isn't merely making a comment, it's also changing the behaviour of the code.
Posted: Wed Sep 21, 2005 12:35 pm
by feyd
coming from a far more type strict language (C++) I prefer it to a degree.. I did create template classes quite often though (typeless) .. I only use typehinting when absolutely necessary, which so far.. I think only one instance in our current framework was it needed.. Most everything works like my template classes and interfaces I used to build

Posted: Wed Sep 21, 2005 1:39 pm
by andre_c
McGruff wrote:andre_c wrote:i also like that it serves for quick documentation when looking at methods
I'm looking for stronger arguments (dependency injection might be one). The thing is a hint isn't merely making a comment, it's also changing the behaviour of the code.
i just noted that as a nice side effect of using it
i wouldn't consider that a good enough reason to use it either
the reason i use it is for enforcing interfaces, so when i create a method that takes an object as one of it's parameters, i know that that object implements a specific interface
i actually think that it makes polymorphism easier, since i just check for an interface an i can have a number of objects that implement it, some objects might actually implement more than one interface too, so i can have the benefit of polymorphism along with some constraints where necessary
Posted: Thu Sep 22, 2005 3:42 am
by Maugrim_The_Reaper
timvw wrote:- Well, PHP5 is out for a year, and so is typehinting for function parameters. Is it really an advantage that you can typehint a function/method parameter or is it somewhat useless in our (loosely typed/typeless) PHP?
- How do you feel about the existence of is_* functions and == vs === in PHP?
- In general, what are the (dis)advantages of typed data in PHP?
I fail to see any disadvantage to type hinting - other than the fact many developers will never have considered it since PHP4 is far looser. I come from C++ also - so maybe my outlook is different.
Try looking at it from another perspective. You build an application for a client, one day they decide to extend it - or some other developer does. They start to pass classes into your own methods (let's say they accept data-only classes (or TransferObjects from a pattern view) to be used/manipulated). Wouldn't you feel a little more secure if a warning/error appeared informing them when they pass invalid classes? Wouldn't the extending developer feel a lot better than staring for hours at your code in search of whatever went wrong (if) rather than a message telling them they've passed an invalid class type, i.e. the wrong data in our example? I like hinting because it battons down more on what client code is doing with my classes - prevents a lot of confusion in some cases.
In either case, it's entirely optional. Choose.
Another point to remember on the topic is that classes (in PHP5) can have more than one type.
Let's say you're passing some logging object around (could be any class - just reaching for simplicity). The client can choose one of three methods (DB, XML, or simple file). Each option forms a separate class - but with an identical interface. Each also extends a common parent (if in PHP5 an abstract). To determine which one to instantiate, you also have a Factory class.
After you instantiate the factory, create an instance of the relevant logging class - you now get an object with two types since your object will inherit its parent type (as well as having its own more specific type). If you wanted to check a valid object is being passed - you could just check it has the type of the parent class (which all log classes will inherit). This is probably just a rambling version of feyd's comment on inheritance mapping
McGruff wrote:The thing is a hint isn't merely making a comment, it's also changing the behaviour of the code.
Yes that is the thing

. And its why it exists. It is in the end useful for those who want it in their OOP. We may want to ensure client code is only passing certain object types - to prevent our code from mangling something based on a client coding mistake.
Another example - I have this hobby of writing PHP games. Now my game is intended to be extendable though plugins. Now I would find type hinting useful to report an error if a plugin writer passed the wrong data (an object with an unexpected type) into a method which writes to the database. Since they'd know right there they passed the wrong thing, they'd be more likely to quickly fix it rather than scratching their heads and emailing me

.
Very useful in my book... You make your interface more specific, reduce emails from confused people, and ensure the next plugin to be released won't contain such silly bugs... That said, I wouldn't use it all the time - its another one of those icky arguable developer preferences...
Posted: Thu Sep 22, 2005 12:32 pm
by McGruff
If you're
testing it's hard to see what benefit hints might bring in terms of catching errors. If object A tries to interact with object B and object B doesn't have the interface required by object A, you'll soon find out about it.
I've been thinking about a refactoring tool for php recently: I'm afraid one of the functions would be "move hint into comment". It is important to document interfaces and where they are being implemented but you don't need hints for that.
You can get into a terrible mess in programming at the drop of a hat. Hints aren't that bad, but they do seem to be running counter to the principle of keep things as simple as you possibly can unless there's some compelling reason to make them more complicated.
Posted: Thu Sep 22, 2005 1:30 pm
by Maugrim_The_Reaper
And if it does have the same interface? I just don't view types as an obstacle to good OOP. Maybe I just like more specific structures. I usually avoid implementing methods which can accept two broadly differing classes - so logically from my own perspective, class typing is just another step in that progression...
Why have to wait for an interface incompatibility to produce an error?

Posted: Thu Sep 22, 2005 1:35 pm
by pilau
What is type hinting?