SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 91 of 91
  1. #76
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    Finland
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily View Post
    Java has to have interfaces, in a dynamically typed language you can just check if the class has a particular method which is easy. Generally if you have a bunch of "instanceof" statements in your code base its not very good (awt isn't very good).
    And having bunch of method_exists calls is better? Isn't it possible that two objects have all the same methods but you have to treat them differently?

  2. #77
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    The point is that unecessary complexity will make code harder to refactor.
    I see. The problem is how we define "unnecessary". I tend to think using typehints is more about coding style than coding concepts, and the "necessity" criteria doesn't apply to a style.

    Quote Originally Posted by Snaily View Post
    Java has to have interfaces, in a dynamically typed language you can just check if the class has a particular method which is easy. Generally if you have a bunch of "instanceof" statements in your code base its not very good (awt isn't very good).
    The whole point of "duck typing" is that you don't check anything. You just call the method, that's all.

  3. #78
    Non-Member
    Join Date
    Sep 2006
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog View Post

    The whole point of "duck typing" is that you don't check anything. You just call the method, that's all.
    This has been an enlightening thread. I have to say that I think one of the best points made in this thread so far has been one that points out a potential advantage of type hinting over duck typing, being that type hinting could catch a bug earlier. The post is here http://www.sitepoint.com/forums/show...3&postcount=33

    I'm not much of a PHP5 user yet but when I do become one I think that I'll enjoy, at least the perceived safety, that type hinting gives.

  4. #79
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And having bunch of method_exists calls is better? Isn't it possible that two objects have all the same methods but you have to treat them differently?
    Its not better, but it eliminates the need for interfaces. Using reflection in general is an indicator of poor design, its rarely needed. If you aren't using reflection then interfaces in PHP offer nothing (except documentation).

  5. #80
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Bogota
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    Test-first isn't a form of perl golf it's more about not adding anything without good reason. Everything has to justify itself as an essential part of the program and clearer code should have no trouble doing that.
    Oh no, I agree with you. What I tried to say is that I've seen situations before where the code turns into a competition of writing the shortest code to make a test pass... and that would be the end of it. This lead to difficult situation maintaining our code.

    Shorter code does not imply cleaner or better code. This doesn't go against TDD. TDD looks for clean code that works.

    The TDD cycle goes:
    1. Write a test
    2. Make it run
    3. Make it right

    I guess our discussion is more about what's right (or clean or whatever). Although it is a very subjective discussion one way to keep it objective might be using code smells to try and measure this. (see the Refactoring book by Martin Fowler).

    Anyway, this was a little bit off topic but it goes back to the question: Are interfaces and type hints addressing a smell in php?

    I think it does. Having a piece of code in many different classes that says

    PHP Code:
    class implements { ... 
    It is clear to the programmer what A is expected to have and how A behaves as many other classes implementing the same interface.

    If that is not there you would need to go class by class seeing which ones have the same group of methods to understand the relationships between said classes.

    Anyway, just my two cents.

    A
    If I have wings, why am I walking?

  6. #81
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Never try and do strict typing on a loose typed platform, it just aint gonna work
    Business as usual is off the menu folks, ...

  7. #82
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    Testing is an excellent way to bring things into focus. It all boils down to one simple question: can you write a test which expresses a real requirement and requires a type hint to make it pass?
    Going back a few days to this, what's a real requirement? Is it a "real requirement" to say that the method should fail if you pass a Foo object instead of a Bar object? If so, a type hint might be the simplest way (but not the only way) to implement it.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  8. #83
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the app is properly (unit) tested, it's safe to assume that incorrect types are not being passed around. You ought to be able to trust your own code. I think the same applies to someone using your library ie it's their responsibility to test that their code integrates correctly with yours. Testing can make some run-time checks unnecessary: the easiest way to deal with failure cases is not to create them in the first place.

    In any case hinting is simply inadequate as a form of testing. Unit tests for the Foo class would specify not just an interface but also the behaviours which this interface exhibits. A class with empty methods could satisfy the hint even though it doesn't do anything. Hints are both too much and not enough.

    What would be a real requirement for hints? That's a good question

    There would have to be some kind of type uncertainty which cannot be ironed out by unit testing. In Phemto the problem is: "I need to create an object which must be associated with a second object. Do I know of a suitable candidate for the second object?" The type uncertainty is deliberate: if "suitable candidate" is defined simply as "implements a named interface", different types can easily be wired together to create different behaviours. Mostly we've been talking about using hints to discover a fatal error state. That's the smell, I think.

  9. #84
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    If the app is properly (unit) tested, it's safe to assume that incorrect types are not being passed around. You ought to be able to trust your own code. I think the same applies to someone using your library ie it's their responsibility to test that their code integrates correctly with yours. Testing can make some run-time checks unnecessary: the easiest way to deal with failure cases is not to create them in the first place.
    If I'm using a library, I might want that kind of safety. In my unit tests, I'm probably replacing the library with a mock object, but what if I've misunderstood what sort of object or value I'm supposed to pass? It's a mistake that's easy to make. I'd be instructing the mock object to expect a different class than what it should be expecting, and the test would pass. A type hint would prevent that.
    Quote Originally Posted by McGruff View Post
    In any case hinting is simply inadequate as a form of testing.
    Of course; hints are not a replacement for testing.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  10. #85
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It would be bad practice only to do interaction-style tests though. You should also have a few integration tests which use real classes, and some acceptance tests. These would show up a problem.

    If you start adding tests like: "testGetFatalErrorIfSecondParameterOfMethodFooDoesNotImplementBar"
    where do you stop? I can't relate that to the domain. It feels like I'm getting bogged down in the code when the test which I really want would be expressed in the language of the domain, asserting some kind of relevant behaviour like "testEmailIsSent" or "testCanAddNewFooRecord". I'm listening to the argument that a library API is a special case but I'm not so sure. Shouldn't: "testFatalErrorIfSomeoneAbusesMyApi" in fact be "testEmailIsSent" or etc...? (a user integration test)

  11. #86
    Resident Code Monkey Chris Corbyn's Avatar
    Join Date
    Nov 2005
    Location
    Melbourne, Australia
    Posts
    713
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    If you start adding tests like: "testGetFatalErrorIfSecondParameterOfMethodFooDoesNotImplementBar"
    where do you stop?
    Nonsense I wouldn't write a test for that. It's obvious what will happen. Testing something like a type-hint would be a bit superfluous and just clutter tests up with things nobody's interested in. Choosing to make use of them simply takes your implementation a slightly different direction but your tests needn't care either way. The only people who will care are non TDDers and if I'm releasing a library to a wide audience, including newbie developers I'm not going to force anybody to test. I do put in my documentation's install stage a section explaining how to run the unit and smoke tests but I can take for granted that 70% of users (a statisitic I admittedly just pulled from thin air) are not going to be doing that. Why are we still only talking about type hints and their use in TDD? It has got me curious enough to begin a poll though

  12. #87
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    It would be bad practice only to do interaction-style tests though. You should also have a few integration tests which use real classes, and some acceptance tests. These would show up a problem.
    First, I'm not sure they always would. Sometimes there's a particular situation that generates an unexpected value. Unless you test specifically for that case, you might not catch it.

    Second, it might be easier and more convenient to find the problem if you have a type hint that gives you an immediate error on calling the library. (This is especially so in the case of an object that's passed in a constructor and just sits there until it fails in a later method call.) In a library that's re-used a lot, it's worth the trouble to make it that convenient.

    I'm arguing in favor of just a little bit of defensive programming.
    Quote Originally Posted by McGruff View Post
    If you start adding tests like: "testGetFatalErrorIfSecondParameterOfMethodFooDoesNotImplementBar"
    where do you stop?
    You have to stop somewhere, but there's no way to make a hard and fast rule about it. I would be making a judgement from experience about where the real pitfalls might be. Anyway, that's the case with all testing. You only write tests for cases that can fail, but that's not a black and white issue.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  13. #88
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    I'm a bit late to this thread, but I've just read every post. My thoughts on hinting below, but first I'd like to introduce my first ever forum pattern:

    "The battle of the double negative"

    Here is a survey question: Rate the advanced PHP forum on a scale of 1 to 5 where 1 is "Guru centric to the point that learners are driven away" and 5 being "Interesting threads keep getting derailed by the same old arguments".

    Note the negative position at each end of the scale. The nice points are 2, 3, 4. The bad ones are 1 and 5.

    Now imagine an argument over this. Someone at 1 who is arguing with someone at 5, say. Both are pushing towards 3 (actually 2 and 4 respectively), but are arguing against each other. Each feels they are standing with their backs to a cliff. The harder each pushes, the more the other seems fanatically insane.

    If hints are at 1 and TDD at 5, then I'm about a 4. I avoid them, and interfaces too unless I need a mocking point.

    That said, I can see the following arguments:

    1) Defining fixed boundaries between teams. Whether each is doing TDD or not, the enforceable nature of the hints is useful. Likely each team runs each other's acceptance tests at install, but probably don't integrate their unit tests. They wouldn't know what to do if they failed anyway. For example, I don't have the unit tests of components I get off of the net integrated into my test suite. A test suite is explicitly run, whereas a type hint is not.

    They can be a latent early warning in this case, although not sufficient.

    2) Testing construction can be annoying and I try to avoid it. Saying that a CorporateAccount is composed of YearlyPaymentModel and UnlimitedApiUse would require testing some secondary behaviour of each. That secondary behaviour is probably already tested in the components, and will likely change. A type hint in the class is quick and easy and adds only a small amount of clutter.

    TDD is great for testing mechanics, and acceptance tests confirm that features are implemented as intended, but if you are building a flexible language of stuff (domain driven design) then you end up testing declarations. Testing declarations is tedious.

    This is one reason Phemto worked off of constructor type hints (I now see). They make sense for places where DI would be used.

    Despite these points, I tend to skip hinting (and the protected/private when I can). Not because I hate it. I just don't need it when I control the code base. Also, they don't test the design.

    A test just says a single event must happen, not how or why. It's design blind, leaving you free to focus on that after writing the test. A contract like type hinting assumes knowledge of the design, as it's a rule. I think this is why they spoil refactoring, and why TDD is a design tool whilst contracts are a testing tool.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  14. #89
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @lastcraft: a well spoken synopsis and an interesting take on how certain thread discussions go.

  15. #90
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by d11wtq View Post
    Nonsense I wouldn't write a test for that. It's obvious what will happen.
    Maybe I didn't explain very well: in effect this is what a hint does when the code executes. Translating that literally into a test case was meant to highlight how out of place it looks as a genuine requirement.

    Anyway everything that possibly could be said probably has been said so it's up to everyone to make up their own mind.

  16. #91
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    Here is a survey question: Rate the advanced PHP forum on a scale of 1 to 5 where 1 is "Guru centric to the point that learners are driven away" and 5 being "Interesting threads keep getting derailed by the same old arguments".
    I wouldn't be able to answer this, and if I tried, I'd probably be censored for using a metaphor involving religion or politics.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •