Object Oriented PHP Arrays

Question 1

I've never tried OO PHP before so I decided to make a simple CMS to learn more. I am having a problem loading values into a multi-dimensional array.

class Article {
  private $index = 0;
  private $article;

  public function Article() {
   $get_articles = mysql_query("SELECT * FROM `articles`");
   while ($result = mysql_fetch_array($get_articles)) {
    echo $result["article"];

    $this->article[$index]["Tags"] = $result["tags"];
    $this->article[$index]["Categories"] = $result["categories"];
    $this->article[$index]["Date"] = $result["date"];
    $this->article[$index]["Article"] = $result["article"];
    $this->article[$index]["URL"] = $result["url"];

    $index++;
   }
  }

  public function getArticle($articleID) {
   return $this->article[$articleID]["Article"];
  }

  public function getTags($articleNumber) {

  }

  public function getCategories($articleNumber) {

  }

  public function getDate($articleNumber) {

  }
 }

The line echo $result["article"] outputs the one and only article value just fine, but apparently doesn't put it into the array?

$art = new Article();
echo $art->getArticle(0);

This doesn't output the article however. Would someone so kindly point out my noob mistake?

Question 2

You didn't initialize your array.

$this->article = array();

while ($result = mysql_fetch_array($get_articles)) {
  $this->article[$index] = array();

Question 3

The main reason is that PHP is moving steadily in the direction of OO programming.

There's nothing wrong with using mysqli_xxx() functions rather than the OOP equivalents; it is exactly the same as far as the code is concerned.

The only issue is that you'll be getting yourself further and further behind the curve in terms of what people think of as well-written PHP code.

It's worth noting that the PDO library, which is considered the ideal for most DB code in PHP is OOP-only. It doesn't have a procedural interface. And nor do most of the other new features added to PHP in the last few versions. If you want to use PHP to its fullest, you need to know OOP anyway.

There's also the point about the ability to create an extension class for your DB -- something like this:

class myDB extends mysqli {
     .... your own stuff here to extend and improve the base mysqli class
}

Of course you can achieve the same thing with procedural code, but it's not as neat as the OOP way. And of course that's only relevant if you actually want to extend the class.

However, as a first step, just moving from mysql_xxx() to mysqli_xxx() is a great start. Moving the whole way to using the OOP interface would be even better, but just switching to the mysqli functions is a good start.

Using the procedural interface to begin with will certainly make the transition away from the old mysql_xx() functions easier, so if switching to the OOP interface is too much of a leap at the beginning, don't feel you have to do it all in one go. Start with a conversion to the procedural mysqli functions, then switch to the OOP methods later on; neither jump will be that big on its own.

Question 4

It's not included.

If it's not included, do you have Any clue why it was not included when type hinting was added?

With the current array implementation, it would require checking all array elements at runtime, because the array itself contains no type information.

It has actually already been proposed for PHP 5.6 but rejected: RFC "arrayof" - interestingly not because of performance issues which turned out to be neglible, but because there was no agreement in how exactly it should be implemented. There was also the objection that it is incomplete without scalar type hints. If you are interested in the whole discussion, read it in the mailing list archive.

IMHO array type hints would provide most benefit together with typed arrays, and I'd love to see them implemented.

So maybe it's about time for a new RFC and to reopen this discussion.

Partial Workaround:

you can type hint variadic arguments and thus write the signature as

function findUserByAge(int $age, User ...$users) : array

Usage:

findUserByAge(15, ...$userInput);

In this call, the argument $userInput will be "unpacked" into single variables, and in the method itself "packed" back into an array $users. Each item is validated to be of type User. $userInput can also be an iterator, it will be converted to an array.

Unfortunately there is no similar workaround for return types, and you can only use it for the last argument.

Question 5

I would extend from the ArrayObject class like this:

class MyArrayObject extends ArrayObject{

    public function offsetGet($name) {
        if($this->offsetExists($name))
            return parent::offsetGet($name);
    }
}

with the function offsetGet() you can access your Array data, so if you call $myObjectArray['test'] the function is called. And then if you check with offsetExists() if the key is seted you will return the value. else the result will be null

EDIT:

And if you want to use this also as an object, you need to add these 2 functions:

public function __get($name){
    return $this->offsetGet($name);
}

public function __set($name, $value){
    $this->offsetSet($name, $value);
}

Question 6

Object-Relational data modeling supports some object-oriented concepts, while still supporting some relational concepts:

Inheritance -- one table can have an IS-A relationship with another table. Likewise custom data types support inheritance.
Distinction between a class and an object (instance of a class) that goes beyond simply the distinction between a table and a row.
Custom or complex data types.
Relational query language.
Referential integrity.

Object-Oriented data modeling is just persistence for objects:

Greater support for complex objects.
No query language -- you just retrieve individual objects like some giant key/value store.
No relational referential integrity -- though you may have one object contain a reference to another object.

Object Oriented PHP Arrays

Answers

Partial Workaround:

Usage:

php,arrays,oop