SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 62
  1. #26
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wibble wobble View Post
    Beginners don't need to know about it and nobody has to use it if they don't want to.
    If one is set not to use third party libraries, maybe, otherwise no. It's likely that
    a lot of third party libraries will use strict type checking, which will force the
    developer to type cast before every library-function call.

    Quote Originally Posted by wibble wobble View Post
    This is essential for overloading, and that is a feature I would LOVE to see in PHP.
    Overloading exists because of static strict type checking. So overloading as I
    see it is a solution to the strict type checking problem. Why would you want
    overloading in PHP?
    I'm under construction | http://igstan.ro/

  2. #27
    SitePoint Addict wibble wobble's Avatar
    Join Date
    Dec 2008
    Posts
    242
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Amenthes View Post
    If one is set not to use third party libraries, maybe, otherwise no. It's likely that
    a lot of third party libraries will use strict type checking, which will force the
    developer to type cast before every library-function call.
    To be fair, by the time someone is using another developer's code, the language should be second nature (otherwise what is the point only learning the basics and using others work for complex tasks?).

    So much PHP code is total crap that it would be great to encourage developers to use strict types. If the encouragement is ignored, there are plenty of other crap libraries out there to use instead.

    Overloading exists because of static strict type checking. So overloading as I see it is a solution to the strict type checking problem. Why would you want overloading in PHP?
    First, because it produces cleaner, nicer code. For example, just now if I want to get comments for a blog post, the code might look like this:

    PHP Code:
    class Comments
    {
      public static function 
    getForPost(Post $post);
      public static function 
    getForPostByPK($postId);

    That's 2 method names for one piece of functionality, and every time I want to get comments, I need to check if I already have the Post object or only the primary key.

    With overloading, I don't need to care what I already have - just use one name for multiple methods and let the run-time environment take care of it.

    PHP Code:
    class Comments
    {
      public static function 
    getForPost(Post $post);
      public static function 
    getForPost(int $postId);
      
    // unrelated note: it would be good to drop the word "function"

    Find freelance jobs from all the major sites in one place:
    on twitter / on the web / twitter rss feed

  3. #28
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wibble wobble View Post
    To be fair, by the time someone is using another developer's code, the language should be second nature (otherwise what is the point only learning the basics and using others work for complex tasks?).
    I think that was Amenthes' point exactly. If the language supports a feature, then you need to be ware of it as a developer and you will run in to code that uses it. So the argument that one can just chose not to use it, doesn't hold. As an analogy, let's say that I don't like firearms because they can be used to hurt me. You may argue that I can just chose not to use them, and that's true for a certain set of cases. It doesn't, however, help me when some one else decides to point it in my direction.

    Quote Originally Posted by wibble wobble View Post
    So much PHP code is total crap that it would be great to encourage developers to use strict types. If the encouragement is ignored, there are plenty of other crap libraries out there to use instead.
    You are implying that strict typing somehow prevents crappy code. That's very subjective, and I disagree.

    Quote Originally Posted by wibble wobble View Post
    That's 2 method names for one piece of functionality, and every time I want to get comments, I need to check if I already have the Post object or only the primary key.
    Overloading is a way to remedy a problem caused by static typing. If you don't use static typing, you could simply do:

    PHP Code:
      public static function getForPost($post_or_id) {
        
    $id is_object($post_or_id) ? $post_or_id->getId() : $post_or_id;
        ...
      } 

  4. #29
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    But with overloading I only have to look at the class API to see what types are supported by a function. Using ifs in the function means I have to read through the method code.

  5. #30
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    But with overloading I only have to look at the class API to see what types are supported by a function. Using ifs in the function means I have to read through the method code.
    A simple phpdoc tag should solve this issue immediately:

    PHP Code:
    class Comments
    {
      
    /**
       * @param int|Post $post
       */
      
    public static function getForPost($post);

    I'm under construction | http://igstan.ro/

  6. #31
    SitePoint Member
    Join Date
    Jul 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Overloading is a way to remedy a problem caused by static typing. If you don't use static typing, you could simply do:

    PHP Code:
      public static function getForPost($post_or_id) {
        
    $id is_object($post_or_id) ? $post_or_id->getId() : $post_or_id;
        ...
      } 
    But that is just the wrong way to code. Obviously it's not a rule or anything, it just is IMO. it goes against the principles of OOP (logic separation) which everyone should be moving towards.

  7. #32
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cts91 View Post
    But that is just the wrong way to code. Obviously it's not a rule or anything, it just is IMO. it goes against the principles of OOP (logic separation) which everyone should be moving towards.
    Care to elaborate on that?

  8. #33
    SitePoint Member
    Join Date
    Jul 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Care to elaborate on that?
    How do you want me to elaborate? The post was pretty clear I think.

  9. #34
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What are "the principles of OOP (logic separation)"?

  10. #35
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wibble wobble View Post
    PHP Code:
    class Comments
    {
      public static function 
    getForPost(Post $post);
      public static function 
    getForPostByPK($postId);

    I don't understand why you need the second variant.

    PHP Code:
    class Comments
    {
      public static function 
    getForPost(Post $post);
    }

    class 
    Post
    {
      public static function 
    getById($id);
    }

    $post Post::get(1);               
    $comments Comments::getForPost($post); 
    Post::get(1) shouldn't query the database, but set up a Query type object for (SELECT * FROM posts WHERE id = 1) which the Comments::getForPost() can use as the basis for its own query either by joining in the comments table

    Code:
    SELECT c.* FROM posts p INNER JOIN comments c ON c.post = p.id WHERE p.id = 1
    Or realising the conditions are as such it can remove the join

    Code:
    SELECT c.* FROM comments c WHERE c.post = 1

  11. #36
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I'd model it the other way around and avoid the need for static ::get methods. This gives you proper polymorphic flexibility as you're not tied to the "Post" and "Comments" classes.

    PHP Code:
    $post = new Post(1); //As Ren stated, this doesn't need to fetch the post data at this stage
    $comments $post->getComments(); 

  12. #37
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As long as it remains optional, which I'd think it would, then type hinting for integers, strings, etc, is a logical extension to what we can already do with objects and arrays.

    And if it is indeed optional, then the whole "for or against" argument is rather moot.

    If you like it, use it. If not, then don't. Case closed.
    <.smarter.web.development.>
    PHP Stuff: Plexus | Chocolate (BDD Framework... coming soon)
    Graphite

  13. #38
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    been looking forward to type hinting for a while. currently i use type hinting for all passed objects, but the solution is incomplete without being able to do primitives.

  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 cts91 View Post
    it goes against the principles of OOP (logic separation) which everyone should be moving towards.
    The principle of OOP is to encapsulate stuff behind an interface. That's it. (And you don't even need public/private/protected to do that).

    If parameters can be the wrong type, well, so too can their hints. We need hints for hints, I say, and yet more hints for the hints of hints, just to be on the safe side.

    Or we could define constraints on behaviour in unit tests. In comparison, hints don't provide much scope for constraining anything. A simple hint is both too much and not enough. What a colossal waste of time implementing them, working with them and discussing them when we should be talking about testing instead. I can hardly think of an example in my own code where I've had to bother about type.

  15. #40
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,578
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I'm not the type to keep up with PHP internals, not of that much interest to me.

    But I do spend some time looking at Symfony code since I used that framework for some large sites I still develop.

    Symfony has used typed parameters for a long time

    PHP Code:
    public function executeIndex(sfWebRequest $request
    And I've noted that PHP does already enforce these types; I once accidentally typoed that class name in a method signature, and it no longer matched and executed.

    My servers all run PHP 5.2. So what exactly does this patch add?

  16. #41
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Hi Dan, currently PHP only allows Object, Interface or Array Type Hinting, this patch would add the ability to Type Hint the others too (integer, string, float etc...).
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  17. #42
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    dan, you can only type hint with complex objects. i believe this patch adds support for primitive PHP types such as int, boolean, string, array.

    question to anyone who knows, it seems everyone is throwing around the terms "typed parameters" and "type hinting" as if they were interchangable, but are they? it appears what the discussion here is about the addition of full "type hinting" support. someone inform me if i'm wrong, but a quick google search tells me "typed parameters" is a slightly different concept.

  18. #43
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally I don't care either way. I have PHPDoc comments, which is sufficient type hinting for me.

    However, if we do get this, then method overloading would be nice. Both making method names longer with qualifiers and adding in explicit type checking is awkward.

  19. #44
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sk89q View Post
    Personally I don't care either way. I have PHPDoc comments, which is sufficient type hinting for me.
    Whereas I'm looking forward to converting a bunch of these...
    PHP Code:
    /**
     * @param int $foo
     * @param string $bar
     */
    function do($foo$bar) {
        
    $foo = (int) $foo;
        
    $bar = (string) $bar
    into the more explicit and cruftless
    PHP Code:
    function do((int) $foo, (string) $bar) { 
    It's not just for functionality, but documentative purposes as well. I care much less for the strictly type checked alternative for much the same reasons many of you've provided, but I feel it's somewhat mandatory to have along with the merely type-casting version. The latter would be much more prevalent and useful even if only in reducing the kind of clutter demonstrated above, but I can come up with uses for the former – hidden deep inside layers of code accepting more lax input, most likely. The case "if it's not of the right type then something's already wrong" seems useful to me.

  20. #45
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Why do you want to force the caller to use a particular implementation, when all you need is conformance to an interface? The only thing this accomplishes, is to add a lot of bureaucracy and book-keeping to the language.
    You lost me here. Of which implementations and interfaces do you speak? I think I was referring to scalar types.

  21. #46
    SitePoint Enthusiast willthiswork's Avatar
    Join Date
    Feb 2003
    Location
    italy
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The whole problem is that many features are added for these hardcore
    full time php programmers, suffering from ruby/python/java/<any> envy.
    Hoping that php with some of their features will gain some academic
    respect. This is wrong (and polemic ).
    Well..personally I couldn't care less for the academic respect. PHP was never intended for that "use". It was intended for quick and efficient web developing, exactly what it does. Having recently switched to C# I found no problem at all in type-casting but also I don't think it is a feature you can't go without

  22. #47
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    @Ezku I think what he means there is that you shouldn't need to have to convert variables before passing them to a method - they should be handled by the method (parameter-typing included).

    For example, say you have a method do submit a mysql query based on user input (only using MySQL for the sake of an example). Do you:

    1. first escape all the input THEN pass it to the method
    2. Pass the input to the method, which escapes it automatically


    By doing the latter you are saving yourself time and code, whilst adding ease.

    It shouldn't be upto the part of code which CALLS the method to do the verification for the method, the method should do that itself. In this case, the method declaration does it FOR you!
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  23. #48
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by elias View Post
    The whole problem is that many features are added for these hardcore full time php programmers –– less educated "programmers" will suffer from any feature that they have to learn.
    You mean PHP is meant to be a toy language unsuitable for use by us "hardcore full time programmers" and thus undeserving of any features we might find useful? I hope you realise how inane this argument is. PHP, even in its current state, is being used by real programmers to solve real problems, and incorporating useful features from "real" languages – such as OOP and closures – is exactly the right way to go about developing the language. Furthermore, I don't expect any of the features being added in PHP 5.3 and later to impede the ability of even some of my barely programming-literate, non-academic friends to create simple CRUD applications like they're used to doing. Hopefully, they'll end up using PDO and be the better for it.

    Yeah, traits would be an incredibly useful feature to have. But it's not a question of either-or – we can have both, and this discussion isn't taking place in place of the one advocating for inclusion of traits to the core. Traits have been discussed in great lengths already and there's an rfc for it in place. Don't think it's being ignored.

    I hope I didn't come off as an elitist *******, but I think you're presenting multiple false dichotomies here that ought to be resolved instead of propagated further.

  24. #49
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Your argument doesn't make you look like an elitist at all. It simply shows you take PHP seriously.

    Many (misinformed) people believe that PHP IS a toy language used as a bridge between noob and programmer, so that they can move onto better languages.

    Sure, people do tend to start with PHP and can learn other languages later (generally of the desktop application variety) but PHP is still the most suitable programming language for web development out there. That it caters for beginners is just another feature, but for it to stay compeditive with stronger languages it needs to compensate for programming techniques found in said languages - e.g. namespaces.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  25. #50
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku View Post
    You lost me here. Of which implementations and interfaces do you speak? I think I was referring to scalar types.
    We are, but primitives have (implicit) interfaces too. For example, if a class implements __toString(), then objects of that class has the same interface as a primitive string has. If you restrict the contract of a function to the concrete type "string", then you are preventing the caller from passing an object that otherwise fulfils the contract. This leads to code with a lot of explicit type-juggling.


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
  •