I regret using PHP
Tuesday 21 September 2021 11:51 AM Beirut Time · 643
Wajdi Alkayal Wajdi Alkayal
I regret using PHP


WMK MOBILE APPLICATIO



☰ open


I regret using PHP

ARTIFICIAL INTELLIGENCE   LASTETS NEWS Top List

BY: 


I regret using PHP.

Right now, I finished a titanic project (around 3 year in the making) and the project is working as expected. However, it feels so fragile and I think I loss a lot of time in some other tasks rather than the own code (including testing/benchmarking libraries, creating our own libraries).

One of the key part of the project is the access to the database, so for this, I use an "orm". For PHP, you can use any ORM in PHP to do the job, however, this project is not easy and it requires some tricks.

First, I tried Laravel and the performance of Laravel (because I want to use its ORM) could be resumed in a single word: SLOW. So I rejected it completely. I tested other ORM and they are also really slow, so I created one from scratch with two goals:

a) simple
b) fast.

And here is the project

https://github.com/eftec/pdoone

And it works (more or less).

Why do I need an ORM?

Because it is not possible to create a project using the primitive functionalities of PHP (PDO in this case), example:

Using PDO
(it is prone to mistakes)

$stmt = $pdo->prepare("SELECT * FROM myTable WHERE name = ?");
$stmt->bindParam(1,$_POST['name'],PDO::PARAM_STR);
$stmt->execute();
$result = $stmt->get_result();
$products=[];
while($row = $result->fetch_assoc()) {
  $product[]=$row; 
}
$stmt->close();

Using my library

$products=$pdoOne
    ->select("*")
    ->from("myTable")
    ->where("name = ?",[$_POST['name']]) 
    ->toList();

Using my library (ORM)

ProductRepo // this class was generated with echo $pdoOne()->generateCodeClass(['Product']);
    ::where("name = ?",[$_POST['name']])
    ::toList();

Then, I found the main problem of PHP: "dynamic typing".

dynamic typing

Let's say we have a function that returns a list of products.

$products=ProductRepo::listall();

However, PHP does not know if we are returning a list of products. We could add type hinting, but (as its name says), it is just a type hinting/validation and nothing more. Type hinting is a cheap solution and it is not foolproof at all.

   function listall():array {
      // code goes here
   }

But, there is another problem. PHP doesn't have the concept of array-of-a-specific-type.

It is Java:

  products=new ArrayList<Product>();

It is c#

  products=new List<Product>();

And it is PHP

  $products=array(); // or simply [], so we could store an object, a number or whatever value here.

objects versus array

Let's say we have a model of an invoice.

class InvoiceDetails {
   public $idInvoiceDetail;
   public $idInvoice;
   public $product;
   public $quantity;
}
class Invoice {
   public $idInvoice;
   public $customer;
   public $date;
   public $invoiceDetails;  // a list of invoicedetails
} 

What if we want to serialize:

   $invoice=new Invoice(); // $invoice is an instance of Invoice
   $json=json_encode($invoice); // $json is the class serialized
   $invoiceback=json_decode($json); // now $invoice is an instance of stdclass.

We could convert it manually but it takes so much resources to have a correct serialization.

So, the best solution is to use an associative array. Why?

   $invoice=['idinvoice'=>1...]; // $invoice is an array
   $json=json_encode($invoice); // $json is the array serialized
   $invoiceback=json_decode($json,true); // now $invoice is an array.

In PHP, we don't need to use models at all. We could use a bit of them to get some type hinting but again, it is not a perfect solution, neither it is foolproof or help in a big project. It also kills the performance considerably (mainly if you want to serialize/de-serialize).

Are libraries the solution?

There are some libraries to help solving those problems. However, they bring new problems: performance. Many PHP libraries use a lot of "hack" solutions to solve the problems of PHP such as serialization, for example using reflections and such. However, they are a minefield and some of them don't care about the performance at all.

But why I regret PHP?

Let's say our initial problem, a function that returns a list of products.

It is PHP

   $products=ProductRepo::listAll();
   // show the first product if any
   if($products!==null && count($products)>0) {
      echo $products[0]->name; // or $products[0]['name'] if array
   }

There is not warranty that this code will work because the PHP language does not really know that $products has a list of products.

It is c#

   List<Product> products=ProductoRepo.listAll();
   if(products!=null && products.Count()>0) {
      console.log(products[0].name) 
   }

It will always works because c# knows that the variable products is a list of products (or null) and there is not other alternative.

And it is the implementation of the function in c#

function listAll() {
    var result=new List<Product>();
    using(var dbase=new BaseExample()) {
        result=dbase.Products.toList();
    }
    return result;    
}

It simple and it works. There is not minefield here.

It uses Entity Framework and it reads from the database, converts the value and returns a list of products. The performance hit is minimum (I tested). Why? First, the system does not need to guess the field (the field exists or it raises an error), it does not need to do type juggling and because C# is a compiled language.

And it is the serialization/de-serialization

string json = JsonSerializer.Serialize(products);
var productsdes = JsonSerializer.Deserialize<List<Product>>(json);

FOR MORE INFO WATTS ME



Social Channels:

TWIITER

FACEBOOK

YOUTUBE

INSTAGRAM



Join Our Telegram Channel for More Insights


WMK-IT W3.CSS


News

Machinlearning
python
Programming
Javascript
Css
Mobile Application
Web development
Coding
Digital Marketing
Web Development
WMK MOBILE APPLICATION[Android/IOS]
WMK-IT
WMK-TECH
Job

Blog post

Web Developer
SMM / CONTENT MANAGER & COPYWRITER
Senior/Lead Python Developer

Related Posts
Graphic design
09 June
The Power of Email Marketing
03 June
Photography
01 June