PHP Recursive function gone wrong, recursion within a do while

1. This is not how you call a method:

   return public function __construct();
   

   It should be $this->__construct();

2. Class constructors don't actually return anything. They are called as an object is initialized but they don't have return values.

3. This:

   $obj => showHand();
   

   should be

   $obj->showHand();
   

4. You're missing a ; after your while, and you're missing a } after that semicolon to close your __construct() method body.

5. I don't know if it's legal to call PHP constructors recursively. Try placing it in a separate method and calling that recursively instead. Or just totally do away with recursion and use a normal while loop.

as pointed out by BoltClock, you don't recursively call construct.

Anyway, you don't need recursion here.

    do{

        if  (in_array ($rand = rand(1,52), $this->_pokerHand))
            continue;

        $this->_pokerHand[] = $rand;
        $this->counter++;    

    } while ($this->_counter < 5)

The constructor is the function that creates a new pokerHand object, or rather it is the method (function) called to initialise the object, you should probably not call it directly.

In that example, the recursion is unnecessary, the loop suffices.

class pokerHand {
    private $_pokerHand = array();
    private $_counter = 0;

    public function __construct (){
        do {
            if  (!in_array($rand = rand(1,52), $this->_pokerHand)) {
                $this->_pokerHand[] = $rand;
                $this->_counter++;
            }
        } while ($this->_counter < 5);
    }

    public function showHand(){
        print_r ($this->_pokerHand);
    }
}

$obj = new pokerHand();
$obj->showHand();

$this->_pokerHand[] = $rand;

I'm no PHP wiz but it looks like you are missing a variable in the brackets after pokerhand to specify which index you are placing a value into.

I believe the following code does what you are wanting to do, using a recursive method, however this is not on the __construct which I believe is confusing.

class pokerHand {

  private $_pokerHand = array();
  private $_counter = 0;

  public function __construct (){
    do{
      $this->_pokerHand[] = $this->pickCard();
      $this->_counter++;
    } while ($this->_counter < 5);
  }

  private function pickCard(){
    if  (in_array ($rand = rand(1,52), $this->_pokerHand) ){
      return $this->pickCard();
    } else {
      return $rand;
    }
  }

  public function showHand(){
    print_r ($this->_pokerHand);
  }
}

$obj = new pokerHand();
$obj->showHand();

I have used a separate method for picking a card which makes things far easier to follow, separating out the loop and card picking.

1. No need for recursion here. It's a fixed size. Just iterate. Recursion is more useful when you're dealing with trees or variable-sized operations. In this case, you know the size is fixed ahead of time.
2. Don't stick that 5 in the middle of a method body. If you change the card game (i.e. the business rules, in douche-speak), what then? By sticking the hand size in a static variable, you can now inherit this class and redeclare the hand size, but everything still works as intended. Note that this maintains the rule that all hands are of equal size, which may not be a very good rule, e.g. if you play a game that involves dealing the entire deck out to all players and you have 5 players, such that not all players have the same size hand.
3. You don't actually need to create a count object. Since you're just filling an array, you already have the count; it's the size of the array. Get rid of that entirely and just use the count() function.
4. It's good that you understand that an assignment expression evaluates to the assigned value, but don't try to write slick code. It's hard to read. "Elegance" for vanity; clarity for sanity.
5. The "public" keyword in that return statement doesn't make any sense. Nor does the function keyword. You're not returning the function when you recurse, you're calling it.
6. The "do" keyword is evil and stupid and should be avoided when possible. Use a "do" when you want to ensure that the body of your loops is always executed at minimum one time, regardless of the evaluation of your predicate. Under every other circumstance, cut that do doo-doo out.

write it like this:

<?php
class pokerHand
{
    private $_pokerHand = array();
    private static $handsize = 5;

    public function __construct ()
    {   
        while(count($this->_pokerHand) < self::$handsize)
        {   
            $card = rand(1, 52);
            if(!in_array($card, $this->_pokerHand))
            {   
                array_push($this->_pokerHand, $card);
            }   
        }   
    }   

    public function showHand()
    {   
        print_r($this->_pokerHand);
    }   
}


$hand = new pokerHand();
$hand->showHand();
?>

I could easily have truncated that a litte bit so that the while loop looks like so:

    while(count($this->_pokerHand) < self::$handsize)
        if(!in_array($card = rand(1, 52), $this->_pokerHand))
            array_push($this->_pokerHand, $card);

But really. Look at that thing. So hard to look at. You go back to that in a month and you'll sit there figuring out what it does; executing the program in your head. Just put more code in there. People get all wound up about "elegance" when in reality all they're doing is wanking off to how short they can write a program.

Meanwhile the Lisp community is laughing their dicks off because everything every other language does can be done in a single amazing Lisp macro that only takes three lines to express but is impossible for 99% of coders to comprehend. But I digress. The point is that "elegance" is often misunderstood as meaning requiring less typing for the programmer, when in reality elegance in code is the marriage of efficiency and clarity; not a measure of code shortness. Writing code for other coders is like the programming equivalent of playing jazz. A million chords and only three people in the audience. How awesome. Pop musicians are successful because they appeal to animal instincts. Programmers are successful when they help a hungry person find a cheeseburger. So code for users; not for coders.

Anyway, I hate it when people get on their soap box and don't just answer the question that was asked, so you can write it recursively like this, but it's stupid:

<?php
class pokerHand
{
    private $_pokerHand = array();
    private static $handsize = 5;

    public function __construct()
    {   
        if(count($this->_pokerHand) >= self::$handsize)
            return $this;

        if(!in_array($card = rand(1, 52), $this->_pokerHand))
            $this->_pokerHand[] = $card;

        return $this->__construct();
    }   

    public function showHand()
    {   
        print_r($this->_pokerHand);
    }   
}


$hand = new pokerHand();
$hand->showHand();
?>

When you're writing a recursive function, the first statement you should write is the statement that gets you out of the recursion. In this case, it's return $this;. That was absent from your solution.

This is the first time I've ever written a recursive constructor. I didn't even know you could do that.

Although this may get downvoted since it doesn't directly answer the question, I wanted to point this out to you since you are a fresh programmer. The __construct is generally only used for initializing an object and there should really never be any real logic within the __construct. The reason for this is any mechanics that are embedded within that function are then going to have to be rewritten into another method within the class, so now you will have duplicate code within the class which will make it harder to maintain.

Also, just as another side note to help, you should think about your actual class and object relationships when you are designing the infrastructure. In this case your "deck" is within the pokerHand class. This doesn't make much sense since the deck is independent of the actual poker hand. A much more usable infrastructure would have a class that handles the Deck and the pokerHand object would take cards out of the Deck.

Again, this can sometimes depend on the programmers personal preferences with development, but atleast pointing out this approach may help you design your object relationships better on future projects.