SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 91
  1. #26
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I see your point but I beg to differ. I see TDD as a design methodology --- I don't see how it is a substitute for correctness (in this case, in-line specification). Further, it does nothing at all to help with 3rd parties who may use your libraries but may not themselves do proper testing coverage. In my view, testing should verify behavior while verifying incoming data (including its shape) should be left as the responsibility of the method code itself. Perhaps it just boils down to a small corner of TDD that seems to be often promulgated but which I can not accept for my own practices. Greetings.

  2. #27
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots View Post
    If anything, it should tend to reduce code-clutter by helping reduce the number of checks one would otherwise want to make to verify passed in objects, not?

    But do you really need to run checks on your passed in objects? In theory it seems useful, but I find that in practice typing errors are much rarer than people think they'll be.

  3. #28
    Resident Code Monkey Chris Corbyn's Avatar
    Join Date
    Nov 2005
    Location
    Melbourne, Australia
    Posts
    713
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yikes what have I started?

    Right, in JavaScript or PHP4 I would do this sort of thing:

    Code:
    this.myMtethod = function(someObject)
    {
        if (someObject.foo && someObject.foo.constructor == Function)
        {
            someObject.foo();
        }
        else throw new Exception("Fatal error: Parameter one must implement method foo()");
    }
    But with a type check that can simply be replaced with:

    Code:
    function myMethod(iFoo $object)
    {
        $object->foo();
    }
    Now if myMethod() called upon loads of different methods from someObject you finish up with a completely messy block of code which does nothing more than the type check does. Or maybe you just check for the presence of the method as and when you'e about to call it? Then you've gotten partway through some crucial sequence of logic only to be stopped dead.

    Perhaps you don't even need to check right? I mean, you should know the method will be there... Well no, not really, not if somebody else is writing the class which gets passed to that method.

    How difficult is it to make sure somebody implements your interface, and how difficult is it to check? I'm well aware that duck typing "does work" but it's not tidy IMO.

    Some of the best PHP developers I've seen make good use of interfaces and abstract classes. The people who seem to find them pointless seem to be the people who don't get the point of them (my boss included) because they never bothered to use them.

  4. #29
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The other thing you can do is:
    PHP Code:
    function myMethod($fooable)
    {
        
    $fooable->foo();

    Fatal error: Call to a member function on a non-object in Command line code on line 1

    is just as fatal as
    Fatal error: Argument 1 passed to MyMethod() must be an object of class iFoo
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  5. #30
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BTW, that was changed in 5.2. Failed typehints are now "recoverable errors" (aka "catchable fatals").

  6. #31
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  7. #32
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    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?
    Properly written tests should be testing the requirements and the behavior, not the implementation. That [the implementation] should be quite irrelevant to the tests.

    So your question is quite beside the point, and quite pointless.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite

  8. #33
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje View Post
    The other thing you can do is:
    PHP Code:
    function myMethod($fooable)
    {
        
    $fooable->foo();

    Fatal error: Call to a member function on a non-object in Command line code on line 1

    is just as fatal as
    Fatal error: Argument 1 passed to MyMethod() must be an object of class iFoo
    Hi Jason.

    I wouldn't characterize those two as being "just as fatal". In the latter case, the object is inspected when it is passed into the method. In the former case, the error occurs only if that particular code-path within the method is executed (assuming some deeper logic than your myMethod() example). So if your test coverage is lacking for some reason, it is conceivable that you may not catch the non-hinted version until you release.

    @McGruff: You don't NEED typehints to write adequate code. I'm only suggesting that they can help (or maybe only helpful to some ). A real requirement? Perhaps something like "the passed object must support these method signatures"?

  9. #34
    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 dreamscape View Post
    So your question is quite beside the point, and quite pointless.
    The DI tool Phemto uses hints to figure out what object to create. If you look at Phemto/tests/phemto_test.php, cutting the hints in the fixture classes Doubler and Adder would produce fatal errors. If you are testing an app which uses Phemto some (integration) tests would do the same until you add hints where needed.

    What other real requirements might there be ie other examples of tests which won't pass until you add hints?

  10. #35
    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 jayboots View Post
    You don't NEED typehints to write adequate code. I'm only suggesting that they can help
    It's part of the test-infected outlook: don't write anything you don't have to. Everything has to justify it's existence and everything is pared down to the minimum needed to satisfy the tests. I think that's an important outlook and worth emphasising. Programming is like rolling a snowball down a hill. Before you know it, you can start a whole avalanche of complexity and confusion.

  11. #36
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    What other real requirements might there be ie other examples of tests which won't pass until you add hints?
    Way to not read what I wrote.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite

  12. #37
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by d11wtq View Post
    Now if myMethod() called upon loads of different methods from someObject you finish up with a completely messy block of code which does nothing more than the type check does. Or maybe you just check for the presence of the method as and when you'e about to call it? Then you've gotten partway through some crucial sequence of logic only to be stopped dead.

    Perhaps you don't even need to check right? I mean, you should know the method will be there... Well no, not really, not if somebody else is writing the class which gets passed to that method.

    How difficult is it to make sure somebody implements your interface, and how difficult is it to check? I'm well aware that duck typing "does work" but it's not tidy IMO.

    Some of the best PHP developers I've seen make good use of interfaces and abstract classes. The people who seem to find them pointless seem to be the people who don't get the point of them (my boss included) because they never bothered to use them.
    You're making two assumptions here:

    1) Type errors are common and important enough to be worth checking for.
    2) Type checking has no disadvantages.

    The first is highly debatable; as I said earlier, in my experience type errors are rare enough that they don't merit code to check for them, and I know I'm not the only one out there who feels that way. People often bring up the argument about your code being used by 3rd parties, but really, those people are much more likely to make mistakes in their logic than in passing incorrect types.

    As for the second, it's commonly accepted that there are trade-offs between static and dynamic typing. With type hints you might gain some security, but you lose some flexibility; changing the types of arguments a method accepts is more work than it would be otherwise, and there's no way to have a argument support multiple types. I have many bits of code in my libraries that accept arrays or iterators; no way to support that with type hints.

    Finally, some people who find interfaces pointless are people who've worked in many languages, and coincidently find their favorite ones are the ones that don't have interfaces, or even classes...

  13. #38
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    The first is highly debatable; as I said earlier, in my experience type errors are rare enough that they don't merit code to check for them, and I know I'm not the only one out there who feels that way. People often bring up the argument about your code being used by 3rd parties, but really, those people are much more likely to make mistakes in their logic than in passing incorrect types.
    They are rare because there exists up-front guards to prevent them from happening; indeed, type errors are typically weeded out early in the development process. So yes, logic errors are more prevalent which makes it a good thing that typehints can help reduce users (3rd party) from looking for otherwise trivial errors (vis-a-vis type) so that they can focus on their logical issues. Type-hinting is not a panacea that will make all errors disappear -- I don't think anyone is advocating that. So suggesting that they are not prevalent erros doesn't make them any less worthwhile to guard against.

    Quote Originally Posted by 33degrees View Post
    Finally, some people who find interfaces pointless are people who've worked in many languages, and coincidently find their favorite ones are the ones that don't have interfaces, or even classes...
    What's that supposed to suggest? I can equally say that "some people who find interfaces have a point are people who've worked in many languages, and coincidently find their favorite ones are the ones that do have interfaces and classes in general." So? What does that prove other than to forward a herd mentality?

    As for the testing issue, let me put it this way by sticking my neck-out a bit more: type checking doesn't merit test cases. Testing is an essential, but not a zero-cost effort; for this class of issue, type-hinting is less expensive and gives other benefits (like documentation), IMHO.

  14. #39
    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 dreamscape View Post
    Way to not read what I wrote.
    I'm sorry perhaps I misunderstood you. OK a test shouldn't expose implementation details (with the exception of interaction tests which expose the interfaces of secondary objects but then that's their whole point). However the implementation details do have to produce the desired behaviour. There are cases where hints are needed - in Phemto for example or perhaps in a refactoring tool - but this is rare. I think the test question is what brings that into focus. It brings everything into focus.

  15. #40
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots View Post
    They are rare because there exists up-front guards to prevent them from happening
    No, type errors are rare even without up-front guards. This is the realization that many people who have gone from statically typed languages to dynamically typed ones have; that the safeguards are not nearly as important as they previously thought they were, because what they guard against simply doesn't happen as much as they thought they would.

    Quote Originally Posted by jayboots View Post
    What's that supposed to suggest? I can equally say that "some people who find interfaces have a point are people who've worked in many languages, and coincidently find their favorite ones are the ones that do have interfaces and classes in general." So? What does that prove other than to forward a herd mentality?
    d11wtq was implying that people who don't use interfaces and abstract classes are people who don't know better. I'm saying that some people who don't like them have enough experience in both statically typed and dynamically typed languages to have made an educated choice.

    Ultimately, the point I want to make is that different typing systems have pros and cons, and that by using type hints and interfaces you lose some things while you gain others.

  16. #41
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape View Post
    Properly written tests should be testing the requirements and the behavior, not the implementation. That [the implementation] should be quite irrelevant to the tests.

    So your question is quite beside the point, and quite pointless.
    Not at all. The point is...if you have a test, and you write some implementation to make it pass (the simplest thing possible) and it passes without the type hint (because the type hint doesn't add functionality) then where is the need for a type hint expressed? If there is no test that fails because of the lack of a type hint, there is nothing more to do. Thats the whole point of TDD - you don't write code until you have a failing test. If its already passed without the type hint, you can stop.

  17. #42
    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 Luke Redpath View Post
    Not at all. The point is...if you have a test, and you write some implementation to make it pass (the simplest thing possible) and it passes without the type hint (because the type hint doesn't add functionality) then where is the need for a type hint expressed? If there is no test that fails because of the lack of a type hint, there is nothing more to do. Thats the whole point of TDD - you don't write code until you have a failing test. If its already passed without the type hint, you can stop.
    I'm sorry, but as much as what you're saying is true until you step away from TDD and into the wider world I disagree. Type hints are friendly documentation at the very least. I consider it almost respectful to my users to provide the interfaces (in addition to the tests). Clarification... umm.. did I say that word already?

    I'm bored of this thread now anyway... it's gone well beyond what I originally asked. I think we'll (respectfully) just agree to disagree.

  18. #43
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Luke Redpath View Post
    and it passes without the type hint (because the type hint doesn't add functionality) then where is the need for a type hint expressed?
    Holy **** do you speak English?

    I said, and I quote myself, "Properly written tests should be testing the requirements and the behavior, not the implementation." Type hinting, interfaces, duck typing, etc, etc are all implementation details. Tests, if properly written, should not care anything at all about the implementation details. Tests should care only about behavior!

    Type hints are irrelevant when it comes to tests, just as it is irrelevant whether you implement the behavior this way or that way. When it comes to testing, behavior is what is important. It doesn't matter whether you implement it this way or that way as long as it does what it should do. Talking about how a specific implementation relates to testing is pointless ******** because you shouldn't be testing implementation details in the first place!

    No one here has said that type hints are to express some kind of behavioral or functional requirement. Quite obviously they don't in nearly all cases. They exist for developers.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite

  19. #44
    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
    I'm sorry, but as much as what you're saying is true until you step away from TDD and into the wider world I disagree.
    I'd much rather people stepped out of the wider world and into TDD... If php was music it would be a kind of free-form jazz where key is optional. Or maybe punk rock where music is optional?

  20. #45
    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
    I'd much rather people stepped out of the wider world and into TDD... If php was music it would be a kind of free-form jazz where key is optional. Or maybe punk rock where music is optional?
    Sorry I wasn't referring to leaving TDD aside. I was referring to the wider audience of PHP developers. I'd say the majority of people who download code I've written (especially something like Swift) are not TDDers. There's a tests directory which is split into "smokes" and "units" where units alone contains about a good 20-30% more code than what's in the library itself but only a fraction of developers will even look at that. I can't change that and if I want to attract a widespread audience (and I do) then I need to be aware of the fact that not everybody will look at my tests

  21. #46
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape View Post
    Holy **** do you speak English?

    I said, and I quote myself, "Properly written tests should be testing the requirements and the behavior, not the implementation." Type hinting, interfaces, duck typing, etc, etc are all implementation details. Tests, if properly written, should not care anything at all about the implementation details. Tests should care only about behavior!

    Type hints are irrelevant when it comes to tests, just as it is irrelevant whether you implement the behavior this way or that way. When it comes to testing, behavior is what is important. It doesn't matter whether you implement it this way or that way as long as it does what it should do. Talking about how a specific implementation relates to testing is pointless ******** because you shouldn't be testing implementation details in the first place!

    No one here has said that type hints are to express some kind of behavioral or functional requirement. Quite obviously they don't in nearly all cases. They exist for developers.
    First things first...show some respect and watch your language. Of course I can read and your tone is unnecessary. May I politely suggest that you re-read my post and if it still isn't clear, read the following.

    Secondly, nowhere am I talking about testing implementation. I'm not sure if I can make this much clearer to you but read this carefully:

    1) You have some kind of behaviour that you want to implement.

    2) You start expressing this behaviour in the form of a failing test.

    3) You write the simplest thing possible to make that test pass.

    I'm sure you are with me so far...the above is TDD in a nutshell. Now, you've written the code (but you haven't written any interfaces or type hints) and your tests pass. For the time being you are done.

    So now back to the point I was trying to make...if you have no failing tests, you have no more code to write. Therefore there is little incentive to write type hints because they don't add anything valuable - your tests are passing, thats the whole point. You can't make them "pass even more".

    The point McGruff was making and the one I was trying to re-iterate you is that the only justification at this point for adding a type hint -- from the point of view of strict TDD that is -- is if you have a failing test that *WILL NOT PASS* unless you have added a type hint. Forget about implementation - the point is that unless you have a specific *BEHAVIOUR* that you cannot get working without a type hint (and one that is expressed as a failing test) then you have no reason to add one.

  22. #47
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good grief you're like a one track broken record that keeps skipping Luke.

    Quote Originally Posted by Luke Redpath View Post
    Forget about implementation
    That is my point. Why are you using TDD to argue against a certain implementation when your tests should care nothing about the implementation? Implementation is irrelevant as far as TDD is concerned (which you seem to agree with), so you cannot use TDD to argue against a certain implementation. You'd have to be incompetent to think you could.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite

  23. #48
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape View Post
    Good grief you're like a one track broken record that keeps skipping Luke.
    Only because despite me contintually try and get my point through to you you continue to completely miss it.

    If you have a test that expresses behaviour and you can make it pass without type hints, why would you add them? You are essentially adding code that isn't necessary. THAT IS MY POINT. You do the simplest thing that works - i.e. the least code needed to make a test pass. Adding type hints is not "adding the least/simplest code necessary". Its adding code for the sake of it.

    If on the other hand you can't make a test pass without them (i.e. the behaviour the test expresses *relies* on those type hints being there for some reason) then you must add them. But (and we finally come back to McGruffs main point)...how many situations can you think of where this would be the case?

  24. #49
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Luke Redpath View Post
    If on the other hand you can't make a test pass without them (i.e. the behaviour the test expresses *relies* on those type hints being there for some reason) then you must add them. But (and we finally come back to McGruffs main point)...how many situations can you think of where this would be the case?
    First, I'd like to say that I'm a bit discouraged that emotions seemed to have got somewhat inflamed in this thread. It is just code talk, after all -- nothing to get heated about

    Now that that is out of the way, I would like to reiterate the position that I initially posited: libraries used by 3rd parties benefit from typehinting and interfaces (and I'd also say abstracts as well, although we haven't ventured there is this thread). For the record, I don't think typehints and interfaces are useful everywhere but I most certainly think there are cases where they add a positive to the developer experience. Moreso, I don't think that appealing to TDD for those cases necessarily adds anything to the debate. Simply, where testing is out of your control, the best one can do is to provide a minimum level of reliability and an immediate sense of knowledge (ie: documentation) to others so that they don't easily run-off the tracks. Having myself used many methodologies and techniques over time to try and address these issues, I have found that interfaces and typehints do help in that regard. That is just my opinion, of course.

    Thanks to all -- it has been interesting to read all of the comments posted here.

  25. #50
    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 d11wtq View Post
    Some of the best PHP developers I've seen make good use of interfaces and abstract classes. The people who seem to find them pointless seem to be the people who don't get the point of them (my boss included) because they never bothered to use them.
    I've been using PHP 5 since early beta. I use abstract classes frequently, but I've moved away from interfaces and type hints after trying them out for a long time.

    I find that type hints slow down refactoring. I still believe they might be useful sometimes, perhaps in very stable code that needs to be re-used in an unstable context.
    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
  •