SitePoint Sponsor |
|
User Tag List
Results 26 to 50 of 59
-
Aug 4, 2006, 01:51 #26
- Join Date
- Feb 2006
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think interfaces and type hinting are tools just like many other features of the language.
Personally I like writing code like:
PHP Code:function array_something(array $array) { }
PHP Code:function array_something($array) {
if(is_array($array)) throw new Exception("first argument should be an array");
}
-
Aug 4, 2006, 02:35 #27
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by zYne
-
Aug 4, 2006, 02:57 #28
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
-
Aug 4, 2006, 03:03 #29
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
Originally Posted by Ezku
-
Aug 4, 2006, 03:58 #30
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by zYne
Code:Fatal error: Argument 1 passed to foo() must be an array, called in /var/www/_sandbox/index.php on line 8 and defined in /var/www/_sandbox/index.php on line 3
Code:Warning: array_reverse() [function.array-reverse]: The argument should be an array in /var/www/_sandbox/index.php on line 5
-
Aug 4, 2006, 04:02 #31
- Join Date
- Feb 2006
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
PHP Code:class A {
/**
* @param $array - simple array
*/
public function foo(array $array) { }
}
PHP Code:class A {
/**
* @param mixed $array -- simple array or an object that implements ArrayAccess and Iterator interfaces
*/
public function foo($array) {
$interfaces = class_implements($array);
if( ! is_array($array) ||
! in_array('ArrayAccess', $interfaces)
! in_array('Iterator', $interfaces)
)
throw new Exception("first argument should be an array or it should implement ArrayAccess and Iterator interfaces.");
}
}
-
Aug 4, 2006, 04:05 #32
- Join Date
- Feb 2006
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
For example think about a framework that takes a config array as a parameter on some method. Then this array is passed from method to method and then some method uses function such as array_reverse. It would be a frustrating task to a developer to figure out why the code threw a warning (propably he would first guess this warning is some bug of the framework itself).
-
Aug 4, 2006, 04:20 #33
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by zYne
Originally Posted by zYne
-
Aug 4, 2006, 05:23 #34
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Arrays and ArrayAccess are a specific case, because it's mixing apples (data-only arrays operated on with procedural functions) with oranges (objects, which have their own behavior).
-
Aug 4, 2006, 08:18 #35
This is the one of the problems with PHP's implementations of Interfaces; if you use a type hint, your method becomes locked into that one type of object. In Java, you don't have this problem since you can simply overload the method, making a version that accepts arrays, another that accepts iterators, etc.
And this is what I find a bit paradoxical about PHP's inclusion of interfaces; in Java they're a way of making your code more agile (and in fact the language would be useless without them), whereas in PHP they actually make your code less agile.
-
Aug 4, 2006, 08:25 #36
- Join Date
- Jul 2002
- Location
- Dallas, TX
- Posts
- 2,900
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Ok, I much better see the downside of PHP's Interface implementation.
However, I'm pleased to discover that I still feel I'm using them properly. As I mentioned earlier, I'm the framework developer on a team of four. I author tightly controlled domain objects. I'm responsible for ensuring conformity to our framework's API.
If one of the other developers needs a feature or change or whatever, they have to come to me for it. So, for my job responsibilities, interfaces (proper) help me enforce the API.
-
Aug 4, 2006, 10:29 #37
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by 33degrees
-
Aug 4, 2006, 17:31 #38
- Join Date
- Sep 2005
- Posts
- 122
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
How does it makes the code less agile? For the code to work correctly you will still have to implement the methods that will eventually be called. Interfaces in PHP just makes this more verbose and explicit, hence the arguments that interfaces are good for documentation.
Personally, I don't use them. I think it just introduces unnecessary clutter, however I fail to see how they would make the code less agile.
-
Aug 6, 2006, 20:38 #39
Originally Posted by shea
-
Aug 7, 2006, 02:44 #40
- Join Date
- Sep 2005
- Posts
- 122
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
So a new method needs to be added to the passed-in object ... regardless of whether you are using an interface, you're still going to have to add that new method to the passed-in object. So where is the increase in cost? That you have to define a function in the interface as well as the class? Barely worth mentioning.
So changes in one place are going to lead to changes in another place regardless of interfaces. The only difference, which I stated earlier, is that with the verbosity of interfaces, we now have to define, at most, one more method signature.
-
Aug 7, 2006, 08:25 #41
Let's use an example: Your client wants you to model some animals, so you create an IAnimal interface. Your animals need to eat food, so you add an eat(Food $food) method to your interface, and then implement your different animals. One day your client decides he'd like to add some goats, and you realise that your goats don't just eat food, sometimes they eat garbage. So what do you do? You need to change your goats so that they simply eat($stuff), but that means changing your interface, which then means changing every single class that implements IAnimal. Based on your initial requirements, you made the assumption that your animals would only ever eat food; but the requirements changed, and your prediction turned out wrong, so now you have to adapt your code to the new requirements, something that is more complex than it could be because of the typehinting. Hence, type hinting (and static typing in general) increases the cost of changes, decreasing agility.
-
Aug 7, 2006, 10:40 #42
- Join Date
- Jul 2004
- Location
- Finland
- Posts
- 73
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thats a design problem. Food is bad name for interface, it should be Eatable, CanBeSwallowed or something like that
-
Aug 7, 2006, 10:56 #43
It's a contrived example; the fact is that there will always be cases where you will need to change the types of arguments your methods should accept, and by locking them in with typehints, you risk needing to make far-reaching changes later.
-
Aug 7, 2006, 14:45 #44
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
....lets say your code is designed so that it can only process food and not garbage. Typehinting an interface is in this case therefore specifies the minimum required contract (which without typehinting, you would probably have to check for in your code anyhow -- unless, perhaps, you rely only on test cases to ensure correctness). Changing requirements often DOES require changing and reviewing code in far reaching ways, not?
-
Aug 7, 2006, 15:07 #45
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
...which surely is an argument to minimise such changes as far as possible.
Personally I wouldn't use hints unles I was using a DependencyInjection tool which requires them. I can't think of a unit test which would produce a false positive for lack of hints. If it works, it works and hints don't change that. You could get false negatives signalling that the constraints need to be relaxed (ie dump the hints). I think it's best to try to strip away everything that's not absolutely essential since this makes refactoring easier.working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
-
Aug 7, 2006, 18:19 #46
Originally Posted by jayboots
Originally Posted by jayboots
-
Aug 7, 2006, 18:46 #47
Originally Posted by 33degrees
I really do not want to start a statically vs. dynamically typed debate (we've all been there before), but I do want to point out that the meta-information that types provide in a language like Java makes it possible for many common types of refactorings to be much simpler than they would be otherwise, due to the existence of tools that can analyze that information. Take something as simple as changing the name of a method. Often times you'll pick a name for your method, and after the design or your application is a little more fleshed out, you'll realize that the name is not as clear as it could be. Often you don't need to change the implementation at all, it's just that the name is inconsistent with other names, or is slightly confusing. Often when working with PHP I'll find myself debating over whether it's confusing enough to warrant having to manually update it across a dozen or more files. Yes, I'm more than aware that there are editors that will do search and replace, even using regex. However, it still takes time to make sure you're not replacing any false matches. Constrast this with Eclipse, where I select the method, hit ALT-SHIFT-R, type the new name, and hit enter. That's all that's required, and I can do it in less than 4 seconds.
That may not seem like a big deal, but every little bit adds up. And renaming methods is just the tip of the iceberg. Really, unless you've got experience with a modern refactoring IDE, you should consider whether there is something you're missing. I know, at least for me, that I'm far more merciless with my refactoring when there are tools to automate some of it for me than I am when I have to do it all by hand. If this could be achieved without static typing, I'd be all over it, but I haven't seen or heard of it yet (outside of the Smalltalk community, which I have on my list to check out at some point...)
Of course I'm sure many would argue that static typing imposes enough other limitations that it results in a net loss in agility, even with automated refactoring tools taken into account. That has not been my experience, but I accept that others may differ. Just wanted to present a different view on the matter...
-
Aug 8, 2006, 00:26 #48
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I still don't see how typehinting impinges on the idea that changing requirements require changing code. If anything, it quickly points out where code will need to be changed. Whether you typehint or not, your methods will need to be aware if suddenly an incompatible (ie: an unexpected) object is passed-in. Typehinting merely states at the outset that a given piece of code has certain expectations. Personally, I don't subscribe to the view of absolute generality -- all concrete solutions have limitations; what is the problem in explicitly declaring them? If you need to refactor and modify code at some point to add more sophistication -- aren't tools (and hints or features at any rate) to flag where issues will arise beneficial in those cases? FWIW, I don't advocate typehinting everything in PHP -- just those cases where minimum conditions need be met unconditionally to prevent code breakage. ...or maybe this is my view because I write a lot of library type code and can't trust what people would do with it
-
Aug 8, 2006, 00:52 #49
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by jayboots
-
Aug 8, 2006, 07:13 #50
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
Bookmarks