SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 31
  1. #1
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PHP5 Typehinting and SimpleTest

    Just curious if anyone had a workaround for using typehinting when using Mock Objects with SimpleTest? (besides not using typehinting at all )

    examples
    PHP Code:
    class JimTest
    {
         function 
    myMethod(TestLogger $logger)
        {
            
    $this->logger $logger;    
        }

    does not work when you pass a mock object"Argument 1 must be an instance of TestLogger" however this does work...

    PHP Code:
    class JimTest
    {
         function 
    myMethod(MockTestLogger $logger)
        {
            
    $this->logger $logger;    
        }

    this would be when using a mock object like

    PHP Code:
    $TestLogger = new MockTestLogger($this);
    $myObj =  new JimTest($TestLogger); 
    thanks all
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

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

    Quote Originally Posted by jplush76
    Just curious if anyone had a workaround for using typehinting when using Mock Objects with SimpleTest? (besides not using typehinting at all )
    There is, but it's ghastly. You have to do this...
    PHP Code:
    Mock::generate('TestLogger''IntermediateLogger');
    class 
    MockLogger extends IntermediateLogger
            
    implements Logger { } 
    The new version will now pass through the type hint.

    This is so painful I obviously have it as a high priority to fix. I wanted to do this for the latest release. Unfortunately I had to rush out an alpha version of the 1.0.1 release, because of all the notices generated by the PHP4.4 disaster. It's still on my TODO through and I am hoping to push another tarball out inside a month.

    Take a look at...
    http://cvs.sourceforge.net/viewcvs.p....420&view=auto
    ...and see if there are any other features you will need.

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

  3. #3
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Isn't this an argument against type hinting in general (the tests are speaking)? Why spoil a perfectly good class which could otherwise accept any kind of object implementing a Logger interface...

    In php4, I've only once needed to make a similar get_class() check on a passed object. That was a rare case involving a sandbox for testing data access classes: queries which try to jump out of the sandbox should be blocked so a special query-checking database class must be used rather than the standard one.

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

    I am not a fan of type hinting, but I have to cater for it for two reasons:
    1) Other people seem to like it (especially IDE users).
    2) It can be handy for Dependency Injection.

    Ho hum.

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

  5. #5
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    Stillwater, MN
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Type hinting seems to defeat the purpose of duck typing, no? It seems to be more of a feature just to make PHP look like Java.

    You would probably lose more time than you gain with the IDE from problems like this.

  6. #6
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From my point of view, type hinting was implemented to make Interfaces useful (without it interfaces would be pretty useless...).

  7. #7
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    From my point of view, type hinting was implemented to make Interfaces useful (without it interfaces would be pretty useless...).
    In a dynamic language, Interfaces are pretty much useless by default. Interfaces are invented for static languages such as Java to make them able to have polymorphism for classes in different inheritance hierarchies.

    In a dynamic language like PHP, interfaces are only a cute design tool.

  8. #8
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It seems to be more of a feature just to make PHP look like Java.
    Not so. Full stop.

    type hinting was implemented to make Interfaces useful
    Spot on. Interfaces are an important tool in todays development, and they are there to be used. Sure they can be misused and abused, but what can't huh? If you implement Interfaces, then you definitely need type hinting to ensure that what you expect is what you get.

    There seams to be a fair number of comments against Interfaces and their use? I can't fathom out why this is the attitude of some members, as Java has got absolutely nothing to do with PHP and it's implementation of Interfaces

  9. #9
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Interfaces are an important tool in todays development, and they are there to be used. Sure they can be misused and abused, but what can't huh? If you implement Interfaces, then you definitely need type hinting to ensure that what you expect is what you get.
    What is the purpose of interfaces, really, in a dynamically-typed language? I agree with your last statement above, but why do we need Interfaces in the first place?

    PHP is dynamically typed. Consider:

    PHP Code:

    class Foo
    {
        function 
    foofoo($tweebee)
        {
            
    $tweebee->bluff();
        }
    }

    class 
    Bar
    {
        function 
    bluff()
        {
            echo 
    'I have a loaded chicken and I\'m not afraid to use it!';
        }
    }

    class 
    Muffin
    {
        function 
    bluff()
        {
            echo 
    'Look out! There\'s a giant panda behind you!'
        
    }
    }

    $foo = new Foo();
    $foo->foofoo(new Bar());
    $foo->foofoo(new Muffin()); 
    What would we really gain if we had this instead:

    PHP Code:

    interface Bluffable
    {
        function 
    bluff();
    }

    class 
    Foo
    {
        function 
    foofoo(Bluffable $tweebee)
        {
            
    $tweebee->bluff();
        }
    }

    class 
    Bar implements Bluffable
    {
        function 
    bluff()
        {
            echo 
    'I have a loaded chicken and I\'m not afraid to use it!';
        }
    }

    class 
    Muffin implements Bluffable
    {
        function 
    bluff()
        {
            echo 
    'Look out! There\'s a giant panda behind you!'
        
    }
    }

    $foo = new Foo();
    $foo->foofoo(new Bar());
    $foo->foofoo(new Muffin()); 
    ...except for a few more words and symbols to write? Type hinting is basically nothing but strong typing in disguise.

  10. #10
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like type hinting for team environments... If I create a framework for developers to use for an extensible login system, creating an interface and enforcing it through type hinting allows for fewer mistakes. If a developer doesn't implement one of the methods I set up to be required then bugs creep into the system.

    If a developer comes down the line in a year and needs to create another supported login feature like a new ldap integration he can just look at the interface to know what the bare minimum methods are needed to just "plug in" to the existing framework. If he doesn't pass the correct interface type or hasn't implmented the correct methods errors are thrown which halts development right away.

    What if I didn't enforce the typehinting or an interface and just hoped they used the right methods... and a developer forgets one method, which causes a subtle bug, then antoher developer needs to create a login class and bases his off that other developers class.. now there are two login cases with bugs etc.

    It just makes sense to me.
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  11. #11
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Enough said I think, but I don't (yet) think that BerisLavLopac is convinced, or indeed, is going to be anytime soon

    I just think that Interfaces in a manner help to inforce your design, as another benifit?

  12. #12
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    What is the purpose of interfaces, really, in a dynamically-typed language? I agree with your last statement above, but why do we need Interfaces in the first place?
    Simple, while the dynamic typing of PHP solves the problem of polymorphism among different classes that interfaces solves for other languages it still fails to solve the enforcement of a a specific interface. A good example might be a framework that might have a Controller interface with a list of methods that would need to be defined for the implementing class to be polymorphic.

    Polymorphism is broken pretty much entirely unless the classes are compatible with each other, this is the main problem that interfaces + type hinting solves in both PHP and any strong typed language.

    Incidentally, can anyone see why they decided to implement type hinting on the "array" data type? I can't see how that's any different from supporting type hinting on primitives, surely it can't be used to enforce polymorphism.

  13. #13
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well I'm pretty much of the view that type hinting is a complete waste of time in php. Superficially it looks like OOP support has been improved but IMO it simply adds unecessary complexity. The best programmers, the ones whose ideas you want to follow, are the people who can make things as simple as possible.

    What happens if I pass the wrong type of class? I'll get a method not implemented error pretty quick. That's pretty much all the interface support I require.

    The only time I've felt I needed to check the class type of a passed-in object was to distinguish between two classes with the same interface: one would silently do some authorisation checks, the standard class does not. That was a rare case easily dealt with by get_class().

  14. #14
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    What happens if I pass the wrong type of class? I'll get a method not implemented error pretty quick. That's pretty much all the interface support I require.
    What happens if you have a situation like this?
    PHP Code:
    class Foo {
        public function 
    something() {
            
    // Do something...
        
    }
    }
    class 
    Bar {
        public function 
    something() {
            
    // Do something completely different
        
    }
    }

    function 
    test ($obj) {
        
    $obj->something();
    }

    // No error, correct effect
    test(new Foo);
    // Undesired effect, no error
    test(new Bar); 
    This would be solved by adding "implements ISomething" to class foo and redeclaring the method signature of function test to "function test (ISomething $obj)". Type-hinting and interfaces are not useless, if they were, they wouldn't have been invented

    The only strange and perhaps pointless thing about type-hinting in PHP is that they're shortly to support hinting for arrays, which serves no purpose other than to enforce a data type (which many people want, perhaps they've caved into pressure and supported hinting for the only data type it's possible to support?)

  15. #15
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would expect to be able to prevent that by testing. Sorry I can't find the link but there's been some discussion before about strong typing v loose typing, and how testing can replace safeguards supplied by strong typing. I'll see if I can dig it out.

  16. #16
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would expect to be able to prevent that by testing.


    This works in so far that the developer(s) using the script also use unit testing, which isn't in all cases, however advantageous unit testing is. I can remember the thread your talking about as well, though looking through my bookmark list, it doesn't appear to be there.

    Could have saved you the search, sorry.

  17. #17
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lazesharp
    Simple, while the dynamic typing of PHP solves the problem of polymorphism among different classes that interfaces solves for other languages it still fails to solve the enforcement of a a specific interface. A good example might be a framework that might have a Controller interface with a list of methods that would need to be defined for the implementing class to be polymorphic.
    What is "enforcement of a specific interface"? You can't "enforce" a class to use an interface of another class, because you can't "make" a class call a certain function -- it will only call it if there is a need.

    We must distinguish between two uses of the word "interface": one is defined as "all public methods of a class", and the other is "a formal language construct that defines an object's type". While all OOP languages have the first (even PHP4), the second makes sense only in environments where typing is static.

    Again, what is "enforcement" of an interface. If an object expects from another object to be a duck, it will expect it to behave like a duck. What happens when you call a method which doesn't exist? You get an error, and the script fails -- obviously, the object wasn't a duck. The only difference between
    PHP Code:
    function foo(Duck $ducky)
    {
        
    $ducky->quack();
    }

    $fido = new Dog();
    foo($fido); 
    and
    PHP Code:
    function foo($ducky)
    {
        
    $ducky->quack();
    }

    $fido = new Dog();
    foo($fido); 
    is that the first example will throw an error a bit earlier than the second. And that is what we have try...catch for.

    So, the problem is not with the interfaces, it's with type hinting. And without them the interfaces don't make much sense.

    This would be solved by adding "implements ISomething" to class foo and redeclaring the method signature of function test to "function test (ISomething $obj)". Type-hinting and interfaces are not useless, if they were, they wouldn't have been invented.
    As I said earlier, they were invented for strongly typed language, and in dynamically typed languages they are pretty much useless. When you have strong types, you must declare the type of a variable being passed as a parameter, and interfaces are the way to assign a type to a variable while still not being specific of its internals. In dynamically typed languages it is irrelevant, as each variable may contain a value of any type.

    In your example: if you have two different classes that share the same interface but with wildly different behavior, you have a design problem. Also, remember: type hinting is not a magical solution -- all it does is raise an error, just as calling the wrong method does. So you use type hinting either as a development tool which prevents you from passing a wrong object during development (which can equally well be prevented by unit testing), or as a protection mechanism which raises an exception when a wrong code is about to be executed on runtime (in which case you have to catch the exception -- just like if there was no type hinting). So, again, I see no benefit to type hinting.

  18. #18
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So, the problem is not with the interfaces, it's with type hinting. And without them the interfaces don't make much sense.
    As I see it, Interfaces and Type Hinting is not actually part of the script it's self, but more as a tool or a means to an end in regards to prevent a developer making an error.

    Looking at an Interface and it's public methods, is a lot easier and less time consuming, that what it is to look at the actual documentation of that given class (and it's dependents).

    or as a protection mechanism which raises an exception when a wrong code is about to be executed on runtime
    You can't catch an error from a mis matched Type Hint via an exception... I started a thread on this point a while back, and there is no solution, ie

    PHP Code:
    // ...
    public function pushDomElement $fragment throws IllegalParameterException {
    // ...

    In Java you can catch the error (of course) but PHP does not support this (yet).

    Maybe this article will contribute something to this discussion?

    http://www.artima.com/designtechniques/interfaces.html Maybe the article for the month prior to this article on Inheritance Vs. Composition may shed some light on the subject as well

    Found this,

    In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about two design principles: program to an interface, not an implementation; and favor object composition over class inheritance.
    Do note,

    program to an interface, not an implementation

    Here is the interview, http://www.artima.com/lejava/article...rinciples.html
    Last edited by Dr Livingston; Jul 29, 2005 at 13:16. Reason: Found something else...

  19. #19
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    You can't catch an error from a mis matched Type Hint via an exception... I started a thread on this point a while back, and there is no solution, ie

    PHP Code:
    // ...
    public function pushDomElement $fragment throws IllegalParameterException {
    // ...

    Might be worth someone writing a patch to PHPs type-hinting to make it throw an InvalidArgumentException instead of an error if PHP has been compiled with SPL (this sort of thing is happening left, right and center at the moment, so I don't see why it'd get rejected).

    To everyone who has a problem with type-hinting, yes, it's there to make interfaces useful. If you think that using interfaces and type-hinting is silly, don't use it! However, many people, myself included, do find many instances where interfaces and type-hinting is still useful, even in a dynamically typed language like PHP (see last few posts for examples).

  20. #20
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Something I havent seen mentioned is the value type-hinting can add for documentation purposes.

    Say you have the classes:
    PHP Code:
    class ObjectRelationalMapper {
       ...
        function 
    selectSatisfying($spec) {
            return 
    $spec->selectSatisfyingElementsFrom($this);
        }
    }
    class 
    Specification {
        ...
        function 
    selectSatisfyingElementsFrom($orm) {
            
    $query $orm->createQuery($this->query);
            
    $query->setParam($this->date->toString());
            return 
    $query->execute();
        }
    }
    $spec = new Specification(new Date(03031980));
    $result $orm->selectSatisfying($spec); 
    In both functions the names of the parameters are either abbreviated or an acronym. Add a type hint and everything is more readable:

    PHP Code:
    class ObjectRelationalMapper {
       ...
        function 
    selectSatisfying(Specification $spec) {
            return 
    $spec->selectSatisfyingElementsFrom($this);
        }
    }
    class 
    Specification {
        ...
        function 
    selectSatisfyingElementsFrom(ObjectRelationalMapper $orm) {
            
    $query $orm->createQuery($this->query);
            
    $query->setParam($this->date->toString());
            return 
    $query->execute();
        }
    }
    $spec = new Specification(new Date(03031980));
    $result $orm->selectSatisfying($spec); 
    In a more complex example with more parameters this can make code much more readable especially for people who have odd variable naming habits.

  21. #21
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    Something I havent seen mentioned is the value type-hinting can add for documentation purposes.
    This is most true. You can get a point through with a code example that much easier if there's type hinting in.

  22. #22
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd actually see this as a good argument against type hinting. Once people start using type hinting as a way to comment code, it's inevitable that they'll also end up making restrictions which weren't really intended or desired.

    You can make things very complicated very easily in programming. The genius is in keeping things as simple as possible. Adding type hinting to php worries me because it doesn't seem to show any kind of clear vision. It's just another thing to trip over.

  23. #23
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I'd actually see this as a good argument against type hinting. Once people start using type hinting as a way to comment code, it's inevitable that they'll also end up making restrictions which weren't really intended or desired.
    Im not sure what youre getting at. What uninteded restriction is inevitable?

    Consider the alternatives for commenting the specification class.

    Say youve just downloaded some program and want to do a quick change to the specification class which is in a file by itself. You know that Specification::selectSatisfyingElementsFrom() takes a parameter named $orm but what is it? With no comments youre basically lost and have to search lots of files for the class that conforms to the duck-type of the $orm var. Or you could use the phpdoc convention:
    PHP Code:
    class Specification {
        ...
        
    /**
        * @param ObjectRelationalMapper $orm
        */
        
    function selectSatisfyingElementsFrom($orm) {
            
    $query $orm->createQuery($this->query);
            
    $query->setParam($this->date->toString());
            return 
    $query->execute();
        }

    or you could write the full object name as the variable:
    PHP Code:
    class Specification {
        ...
        function 
    selectSatisfyingElementsFrom($objectRelationalMapper) {
            
    $query $objectRelationalMapper->createQuery($this->query);
            
    $query->setParam($this->date->toString());
            return 
    $query->execute();
        }

    Or you can use a type-hint.

    I prefer writing the whole class name as a variable but sometimes that is very tedious for very long class names.

    Sometimes the object is polymorphic and you cant write the actual class name so you need to use an interface named variable.

    For me type hinting can make code much more readable and thats allways a plus.

  24. #24
    SitePoint Enthusiast
    Join Date
    Jul 2005
    Location
    United Kingdom
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Type-hinting, while self-documenting in a manner of speaking is not documentation. Type-hinting enforces type restrictions, documentation does not. This may sound trivial, but if you consider that type-hinting affects the actual running of the application, whereas documentation has no effect on the functionality, that's a big thing.

    When weighed against the advantages of type-hinting, I really can't see a disadvantage to it that is compelling enough. Especially once you get into serious OOD and designing reusable code.

  25. #25
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Sorry I can't find the link but there's been some discussion before about strong typing v loose typing, and how testing can replace safeguards supplied by strong typing.
    You're probably thinking of Bruce Eckel's Strong typing vs. Strong testing, mentioned in the Type Checking PHP Precompiler thread?

    Quote Originally Posted by BerislavLopac
    What is the purpose of interfaces, really, in a dynamically-typed language? I agree with your last statement above, but why do we need Interfaces in the first place?
    I'd like to play the Refactoring tool card on that one; consider the first Foo, Bar and Muffin example from #9; what if I wanted to do a RenameMethod refactoring of Bar#bluff()?

    This would pose no real problems with the code from the second example (with the Bluffable interface and type hint) I imagine?

    Of course, we'd have to have a decent refactoring tool to begin with
    Per
    Everything
    works on a PowerPoint slide


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
  •