🎁 Perplexity PRO offert

30 jours gratuits

Téléchargez Comet, connectez votre compte et posez votre première question.

Activer l'offre →

Stop Trying to Turn PHP into Java: Why Loose Typing is Your Best Asset in the AI Era

🧠 Introduction: The Guilt of declare(strict_types=1);

I’m going to be honest with you. How many times have you added declare(strict_types=1); at the top of your PHP files, not because it was necessary, but because you wanted to feel “professional”?

For years, the PHP community (pushed by the Symfony ecosystem and PSR standards) has done tremendous work to professionalize the language. We want PHP to look like Java or C#. We want return types, typed properties, strict exceptions. We’ve been taught that “Type Juggling” (automatic type conversion, like adding “10” and 5) is absolute evil, the source of all bugs.

But today, the tide is turning. With the explosion of generative AI and LLMs (Large Language Models), we’re no longer coding in a deterministic world. We’re coding in a probabilistic world.

What if I told you that this PHP “flexibility” you’re trying to hide under the rug is actually the only thing that will prevent your PrestaShop store from crashing in the face of AI hallucinations?

Today, we’re going to deconstruct the myth of strict typing at all costs and see how Loose Typing can become your secret productivity weapon.

⚡ Part 1 – Context: The Dogma of Purity vs. The Reality of the Web

The web is messy. It’s a reality we often forget.

The HTTP protocol is text-based. HTML forms send text. Databases (MySQL) often return strings, even for integers.

PHP was created to be the “glue” of this chaotic web. Its historical philosophy is: “I’ll try to understand what you want to do, even if you express yourself poorly.”

The Illusion of Control

The modern “Clean Code” trend seeks to impose absolute rigidity. If I expect an int and receive the string “42”, my application must crash (TypeError Exception). This is healthy for internal business logic (calculating VAT), but it’s disastrous for application boundaries (Input/Output).

Why? Because when you connect your application to the real world (third-party APIs, supplier CSV files, user inputs), the real world doesn’t respect your strict types.

And the worst student in the “Real World” class is Artificial Intelligence.

🚀 Part 2 – Analysis: When AI Doesn’t Respect Your Contracts

Integrating an AI (like GPT-5) into a PrestaShop module means accepting to work with a brilliant but slightly drunk partner.

You ask the OpenAI API to output JSON to create a product sheet. You explicitly tell it in the prompt: “The ‘weight’ field must be an integer representing grams”.

9 times out of 10, the AI will respond: {"weight": 500}.

But the 10th time, because it “hallucinated” or misinterpreted the context, it will respond: {"weight": "500g"} or {"weight": "approximately 500"}.

The Crash of Strict Languages

In a rigid language (Java, Go, or PHP in strict mode), here’s what happens:

  1. Your DTO (Data Transfer Object) expects an int.
  2. The API returns a string.
  3. Fatal Error / Uncaught TypeError.
  4. The process stops. The product sheet isn’t created. You must code an error handler, log the problem, and maybe even retry the request (which costs money and time).

The Magic of PHP’s “Type Coercion”

PHP, on the other hand, is a diplomat. It has what’s called “Type Coercion”. It’s the ability to transform data on the fly to fit the slot, without making a fuss.

$weight = (int) "500g";  // Result: 500
$price = (float) "19.99€";  // Result: 19.99

This is often criticized, but in a context of unstructured data (like that from AI), it’s incredible resilience. PHP can extract value where other languages give up.

🧮 Part 3 – Practical Application: Resilient “Glue Code”

Let’s take a concrete example of a PrestaShop module that generates product descriptions and technical specifications via OpenAI.

The “Dogmatic” Approach (To Avoid Here)

<?php
declare(strict_types=1);

class ProductFeature {
    public function setWeight(int $weight): void {
        $this->weight = $weight;
    }
}

// AI response: $data = ['weight' => '1.5 kg'];
try {
    $feature = new ProductFeature();
    // CRASH HERE: Argument 1 passed to setWeight() must be of type int, string given
    $feature->setWeight($data['weight']);
} catch (\TypeError $e) {
    // We lose the data, must handle the error...
    Logger::log("AI returned garbage again");
}

The “Pragmatic” Approach (The PHP Way)

Here, we use PHP’s flexibility to “clean” AI input without writing 50 lines of validators.

<?php
// No strict_types here. We're in the "dirty" I/O zone.

class ProductFeatureImporter {
    public function importData(array $aiResponse) {
        // AI returns "1.5 kg"? No problem.
        // PHP's (float) cast is "greedy", it takes what it can from the beginning.

        $weight = (float) $aiResponse['weight'];
        // Result: 1.5 (PHP extracted the number and ignored " kg")

        // AI returns "1200" as string?
        $stock = (int) $aiResponse['stock'];
        // Result: 1200 (int)

        // We then pass this clean data to our strict PrestaShop model
        $product = new Product();
        $product->weight = $weight;
        $product->save();
    }
}

Why is this superior in this context?

  1. Zero crashes: Your import script doesn’t stop for a triviality.
  2. Implicit cleaning: PHP does the “Sanitization” work for free via casting.
  3. Dev speed: You don’t need to write complex “Transformers” for every possible field the AI might misformat.

PrestaShop uses this philosophy everywhere. Look at the Tools::getValue('param') method. It doesn’t crash if the parameter doesn’t exist, it doesn’t crash if the type is wrong. It makes the service robust.

🌍 Part 4 – Vision: The “Backend Prompt Engineer” Developer

This approach changes our vision of the profession.

For 10 years, we’ve been taught to be cathedral architects, where each stone must be perfectly carved (typed). If a stone protruded by a millimeter, we refused construction.

In the AI era, we become Chaos Managers.

AI is a torrent of creative, powerful, but disorderly data. Our role isn’t to block this torrent with rigid dams (strict typing), but to channel this water with flexible pipes (loose typing) so it arrives cleanly in our database.

The developers who will best succeed at AI integration aren’t code purists. They’re those who accept data imperfection and use the most tolerant tools to process it.

PHP’s future isn’t to become C#. PHP’s future is to be the best “glue” language for orchestrating AI models.

🎯 Conclusion

Don’t get me wrong: for the core of your business logic (calculating a cart total, managing VAT), continue using strict typing. There, rigor is mathematical.

But at your application’s boundaries, where you talk with AI, with users, or with external APIs: release the pressure.

Remove that declare(strict_types=1);. Let PHP do its type juggling magic. You’ll gain development speed and, against all expectations, your application will be more resilient to AI hallucinations.

Code perfection isn’t in its rigidity, but in its ability to absorb reality. And reality is poorly typed.

See you soon for more pragmatism! 🚀

Questions Fréquentes

Isn't strict typing always preferable?

Strict typing is excellent for internal business logic. But at application boundaries (APIs, AI, user input), loose typing offers valuable resilience against imperfect data.

Do these principles apply to other languages?

Yes! The concept of ‘defensive programming’ at system boundaries applies everywhere. But PHP has the advantage of having this flexibility built in natively.

Can I mix strict and loose typing in the same project?

Absolutely! It’s even recommended: strict for your business core, loose for your adapters/controllers that interact with the outside world.