Typed or not-typed data?
Moderator: General Moderators
Typed or not-typed data?
- 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?
- 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?
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Re: Typed or not-typed data?
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:- 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?
I love and use both, heavily.timvw wrote:- How do you feel about the existence of is_* functions and == vs === in PHP?
so long as there is explicit and implicit conversions of base types, along with accurate handling of inheritance mapping, I love it.timvw wrote:- In general, what are the (dis)advantages of typed data in PHP?
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.
Except.. I'm not using DependencyInjection and it could be useful for that.
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.feyd wrote:the nice part is you don't have to use typehinting if you don't want to
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.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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 
- andre_c
- Forum Contributor
- Posts: 412
- Joined: Sun Feb 29, 2004 6:49 pm
- Location: Salt Lake City, Utah
i just noted that as a nice side effect of using itMcGruff wrote: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.andre_c wrote:i also like that it serves for quick documentation when looking at methods
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
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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.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?
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
Yes that is the thingMcGruff wrote:The thing is a hint isn't merely making a comment, it's also changing the behaviour of the code.
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...
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.
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.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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?
Why have to wait for an interface incompatibility to produce an error?