Senior 5 min · March 06, 2026

PHP Namespace Mismatch — Autoloader Fails Silently

A single character mismatch in PHP namespace breaks PSR-4 autoloading silently.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • PHP namespaces group classes under a virtual path to avoid name collisions
  • Declare namespace at the top of each file: namespace App\Services;
  • 'use' creates an alias — it does not load the file or trigger autoloading
  • Performance: zero overhead — namespaces are compile-time labels
  • Production gotcha: global classes like \DateTime must be imported explicitly inside a namespace
Plain-English First

Imagine two people in your office are both named 'Sarah'. When someone shouts 'Sarah!', chaos ensues. So you start saying 'Sarah from Accounting' and 'Sarah from Marketing' — problem solved. PHP namespaces work exactly like that. When two libraries both have a class called 'Logger' or 'Request', PHP needs a way to tell them apart. Namespaces give each class a unique address so there's never any confusion about which one you mean.

The moment your PHP project grows beyond a handful of files, you will almost certainly pull in third-party libraries. Maybe you're using a Slack notification library and a logging library at the same time. Both ship a class called 'Logger'. Without namespaces, loading both would cause a fatal error — PHP simply can't have two classes with the same name in the same script. That's not a hypothetical edge case; it's a collision that happens constantly in real projects, and it's the exact problem namespaces were built to solve.

Namespaces arrived in PHP 5.3 as a direct response to the naming-convention hacks developers were forced to use before them. The old pattern was to prefix every class with a long string like 'Vendor_Package_ClassName' — which worked, but was noisy, fragile, and painful to type. Namespaces let you group related code under a logical path, much like a file system, and then import what you need with a clean 'use' statement. The result is code that's readable, maintainable, and collision-proof.

By the end of this article you'll understand why namespaces exist (not just what the syntax looks like), how to declare and nest them, how to alias them for convenience, and how they interact with autoloaders in a real project. You'll be able to write namespace-aware code that follows PSR-4 conventions — the same standard used by Laravel, Symfony, and virtually every modern PHP package.

Why Name Collisions Are a Real Problem — And How Namespaces Fix Them

Before we write a single line of namespace code, let's feel the pain that makes namespaces necessary. Picture a project that requires two Composer packages. Package A ships a class called 'Response' that formats API output. Package B also ships a class called 'Response' that wraps HTTP status codes. The moment PHP tries to load both, it throws a fatal error: 'Cannot declare class Response, because the name is already in use.'

The old workaround was manual prefixing: 'ApiFormatter_Response' and 'HttpWrapper_Response'. It worked, but every class name became a sentence. Namespaces replace that convention with a language-level feature. You declare a namespace at the top of each file, and PHP treats it as part of the fully-qualified class name. 'ApiFormatter\Response' and 'HttpWrapper\Response' are now completely different identifiers, even though both classes are called 'Response' in their own files.

That separation is the entire point. Namespaces don't change how your class behaves — they change its address. Think of it as the difference between a filename and a full file path. 'config.php' is ambiguous. '/app/Http/config.php' is not.

collision_demo.phpPHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<?php
// FILE 1: vendor/slacknotify/src/Logger.php
namespace SlackNotify\Logging;  // This file lives in the SlackNotify\Logging namespace

class Logger
{
    public function log(string $message): void
    {
        // Pretend this sends a Slack message
        echo "[SlackNotify] " . $message . PHP_EOL;
    }
}


// FILE 2: vendor/monolog/src/Logger.php
namespace Monolog;  // This file lives in the Monolog namespace

class Logger
{
    public function log(string $message): void
    {
        // Pretend this writes to a log file
        echo "[Monolog] " . $message . PHP_EOL;
    }
}


// FILE 3: index.php  — Using BOTH classes with zero conflict
require 'vendor/slacknotify/src/Logger.php';
require 'vendor/monolog/src/Logger.php';

// 'use' imports the fully-qualified name so we can write short aliases
use SlackNotify\Logging\Logger as SlackLogger;  // alias to avoid ambiguity
use Monolog\Logger as MonologLogger;             // alias to avoid ambiguity

$slackLogger   = new SlackLogger();    // creates SlackNotify\Logging\Logger
$monologLogger = new MonologLogger();  // creates Monolog\Logger

$slackLogger->log('User signed up');    // routes to SlackNotify version
$monologLogger->log('User signed up');  // routes to Monolog version
Output
[SlackNotify] User signed up
[Monolog] User signed up
Why Aliases Matter:
When you 'use' two classes that share a short name (both called Logger here), PHP requires you to alias at least one of them. Omitting the alias causes 'Cannot use SlackNotify\Logging\Logger as Logger because the name is already in use.' Aliases aren't just style — they're sometimes mandatory.
Production Insight
In production, name collisions hit hardest during dependency upgrades. A vendor updates to version 2 and adds a class that collides with another package. You don't find out until the autoloader fails in the middle of a deployment.
Rule: always run a 'composer validate' and a quick smoke test that instantiates key classes before rolling out any dependency change.
Key Takeaway
The fully-qualified class name is the absolute identifier.
'use' is just a local alias — it does not prevent collisions, the namespace does.
Always alias when two imported classes share the same short name.

Declaring, Nesting, and Structuring Namespaces the PSR-4 Way

A namespace declaration must be the very first statement in a PHP file — before any other code, before any require calls, and before any HTML output. The only exception is the 'declare(strict_types=1)' directive, which may appear before it.

Namespaces mirror directory structure in PSR-4, the autoloading standard used by Composer. If your class lives at 'src/Services/PaymentGateway.php', its namespace should be 'App\Services' and its class name 'PaymentGateway'. When Composer's autoloader sees 'new App\Services\PaymentGateway()', it knows exactly which file to load. This is not a coincidence — it's the contract PSR-4 defines.

Sub-namespaces use backslashes as separators. Think of them like folders: 'App\Http\Controllers' is just 'App' containing 'Http' containing 'Controllers'. There's no technical limit to nesting depth, but beyond three or four levels it usually signals that your directory structure needs a rethink, not more nesting.

You can also group multiple namespace declarations in one file using the curly-brace syntax, but don't. It's valid PHP but it's confusing. One file, one namespace, one class — that's the convention the entire ecosystem follows.

PaymentGateway.phpPHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<?php
declare(strict_types=1);  // declare() is the ONE thing allowed before namespace

namespace App\Services\Payments;  // mirrors the directory: src/Services/Payments/

// No imports needed yet — everything in THIS namespace is available by default

class PaymentGateway
{
    private string $providerName;
    private float  $transactionFee;

    public function __construct(string $providerName, float $transactionFee)
    {\n        $this->providerName   = $providerName;\n        $this->transactionFee = $transactionFee;\n    }

    public function charge(float $amount): string
    {
        // Calculate total including the gateway's processing fee
        $totalCharged = $amount + $this->transactionFee;

        return sprintf(
            'Charged $%.2f via %s (includes $%.2f fee)',
            $totalCharged,
            $this->providerName,
            $this->transactionFee
        );
    }
}


// ── index.php ─────────────────────────────────────────────────────────────────
// In a real project Composer autoloads this. Here we require manually.
require 'PaymentGateway.php';

use App\Services\Payments\PaymentGateway;  // import the fully-qualified name

$stripeGateway = new PaymentGateway('Stripe', 0.30);  // $0.30 flat fee
$paypalGateway = new PaymentGateway('PayPal', 0.49);  // $0.49 flat fee

echo $stripeGateway->charge(19.99) . PHP_EOL;
echo $paypalGateway->charge(19.99) . PHP_EOL;
Output
Charged $20.29 via Stripe (includes $0.30 fee)
Charged $20.48 via PayPal (includes $0.49 fee)
PSR-4 Golden Rule:
Map your top-level namespace to your 'src/' directory in composer.json under 'autoload.psr-4'. Once that's set, you never write another 'require' statement for your own classes. Composer's autoloader handles every 'new App\...' call for you, following the namespace-to-directory contract automatically.
Production Insight
PSR-4 breaks silently when a file is moved without updating the namespace declaration. The file still exists, but composer's autoloader can't find the class. Debugging this wastes hours.
Rule: never move a file without immediately updating its namespace. CI should check namespace-to-path consistency.
Key Takeaway
One namespace per file, one file per class.
Namespace path must mirror the file system path.
Composer's psr-4 mapping is your single source of truth — configure it once and never require files manually.

The 'use' Keyword, Aliases, and Referencing Global PHP Classes

The 'use' keyword is not an import in the traditional sense — it doesn't load any file. It's purely an aliasing instruction that tells PHP: 'when I write DateTime in this file, I mean the fully-qualified \DateTime'. This distinction matters because developers sometimes assume 'use' triggers autoloading. It doesn't. Autoloading is triggered by instantiation.

When you're inside a namespace and you reference a built-in PHP class like 'DateTime', 'Exception', or 'ArrayObject', PHP first looks for that class in your current namespace. If it doesn't find 'App\Services\DateTime', it should fall back to the global namespace — but this fallback only applies to classes, not functions or constants. That asymmetry trips people up constantly.

The safest habit: prefix any global PHP class with a backslash ('\DateTime', '\Exception') when inside a namespace, or add 'use DateTime;' at the top of the file. Both approaches are explicit and eliminate the ambiguity entirely.

Aliases let you shorten verbose fully-qualified names or resolve same-name conflicts. 'use Carbon\Carbon as Date' means you type 'new Date()' everywhere instead of 'new Carbon\Carbon()'. Aliases are local to the file — they don't affect other files.

OrderProcessor.phpPHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
declare(strict_types=1);

namespace App\Http\Controllers;

// Import a third-party class with a long namespace — alias it for brevity
use App\Services\Payments\PaymentGateway;
use App\Services\Payments\PaymentGateway as Gateway;  // alias: type 'Gateway' instead

// Import global PHP classes explicitly — don't rely on implicit fallback
use DateTime;      // tells PHP: DateTime means \DateTime, the global built-in
use RuntimeException;  // same for exceptions

class OrderProcessor
{\n    private Gateway $paymentGateway;  // using the alias 'Gateway' — cleaner!\n\n    public function __construct(Gateway $paymentGateway)\n    {\n        $this->paymentGateway = $paymentGateway;\n    }

    public function processOrder(string $orderId, float $total): array
    {\n        if ($total <= 0) {\n            // 'RuntimeException' resolves to global \\RuntimeException because of our 'use' above\n            throw new RuntimeException(\"Order {$orderId} has an invalid total: {$total}\");\n        }\n\n        $chargeResult = $this->paymentGateway->charge($total);\n\n        // 'DateTime' resolves to global \\DateTime because of our 'use' above\n        $processedAt = new DateTime();\n\n        return [\n            'order_id'     => $orderId,\n            'result'       => $chargeResult,\n            'processed_at' => $processedAt->format('Y-m-d H:i:s'),\n        ];\n    }\n}\n\n\n// ── run_order.php ─────────────────────────────────────────────────────────────\nrequire 'PaymentGateway.php';\nrequire 'OrderProcessor.php';\n\nuse App\\Http\\Controllers\\OrderProcessor;\nuse App\\Services\\Payments\\PaymentGateway;\n\n$gateway   = new PaymentGateway('Stripe', 0.30);\n$processor = new OrderProcessor($gateway);\n\n$result = $processor->processOrder('ORD-7821', 49.99);\n\nforeach ($result as $key => $value) {\n    echo $key . ': ' . $value . PHP_EOL;\n}",
        "output": "order_id: ORD-7821\nresult: Charged $50.29 via Stripe (includes $0.30 fee)\nprocessed_at: 2024-03-15 14:22:07"
      }

Real-World Pattern — Namespaces + Autoloading in a Mini MVC Project

Knowing the syntax is one thing. Understanding how it all fits together in a real project is what separates juniors from seniors. In every modern PHP project — Laravel, Symfony, or your own framework — namespaces and Composer's PSR-4 autoloader work as a pair. You never see 'require_once' littered through the codebase because the autoloader handles every class load for you.

Here's the mental model: you define a mapping in 'composer.json' that says 'App\' maps to 'src/'. Composer generates an autoloader file. When PHP encounters 'new App\Models\Product()', the autoloader converts that namespace to a path — 'src/Models/Product.php' — and loads it. The namespace is the address; the file system is the map.

The example below simulates a mini e-commerce slice: a Product model, a ProductRepository, and a controller that ties them together. Notice how every class sits in a namespace that mirrors its folder, how 'use' statements read like a dependency manifest at the top of each file, and how the whole thing hangs together without a single manual require in the business logic.

mini_mvc_demo.phpPHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
/**
 * SIMULATED DIRECTORY STRUCTURE (in a real project, Composer handles the requires):
 *
 * src/
 *   Models/Product.php          -> namespace App\Models
 *   Repositories/ProductRepo.php -> namespace App\Repositories
 *   Controllers/ShopController.php -> namespace App\Controllers
 * index.php
 *
 * composer.json autoload section:
 * "autoload": { \"psr-4\": { \"App\\\\\": \"src/\" } }\n */\n\n// ── src/Models/Product.php ────────────────────────────────────────────────────\nnamespace App\\Models;\n\nclass Product\n{\n    public function __construct(\n        public readonly int    $id,\n        public readonly string $name,\n        public readonly float  $price,\n        public readonly int    $stockQuantity\n    ) {}\n\n    public function isInStock(): bool\n    {\n        return $this->stockQuantity > 0;  // simple stock check\n    }\n\n    public function getFormattedPrice(): string\n    {\n        return '$' . number_format($this->price, 2);  // format to 2 decimal places\n    }\n}\n\n\n// ── src/Repositories/ProductRepository.php ───────────────────────────────────\nnamespace App\\Repositories;\n\nuse App\\Models\\Product;  // import Product from the Models namespace\n\nclass ProductRepository\n{\n    /** @var Product[] */\n    private array $products = [];\n\n    public function __construct()\n    {\n        // Seed with demo data — in production this would query a database\n        $this->products = [\n            new Product(1, 'Mechanical Keyboard', 129.99, 14),\n            new Product(2, 'USB-C Hub',            39.99,  0),  // out of stock\n            new Product(3, 'Monitor Stand',         59.99,  7),\n        ];\n    }\n\n    /** @return Product[] */\n    public function findAllInStock(): array\n    {\n        // Filter to only products with stock > 0\n        return array_filter($this->products, fn(Product $p) => $p->isInStock());\n    }\n\n    public function findById(int $productId): ?Product\n    {\n        foreach ($this->products as $product) {\n            if ($product->id === $productId) {\n                return $product;  // found it — return immediately\n            }\n        }\n        return null;  // not found — return null, let the caller decide what to do\n    }\n}\n\n\n// ── src/Controllers/ShopController.php ───────────────────────────────────────\nnamespace App\\Controllers;\n\nuse App\\Repositories\\ProductRepository;  // import the repository\nuse RuntimeException;                    // global PHP exception — explicit import\n\nclass ShopController\n{\n    private ProductRepository $productRepository;\n\n    public function __construct(ProductRepository $productRepository)\n    {\n        // Dependency injected — no 'new ProductRepository()' buried in here\n        $this->productRepository = $productRepository;\n    }\n\n    public function listInStockProducts(): void\n    {\n        $inStockProducts = $this->productRepository->findAllInStock();\n\n        echo \"=== In-Stock Products ==\" . PHP_EOL;\n        foreach ($inStockProducts as $product) {\n            echo sprintf(\n                \"  [%d] %-22s %s (%d in stock)%s\",\n                $product->id,\n                $product->name,\n                $product->getFormattedPrice(),\n                $product->stockQuantity,\n                PHP_EOL\n            );\n        }\n    }\n\n    public function showProduct(int $productId): void\n    {\n        $product = $this->productRepository->findById($productId);\n\n        if ($product === null) {\n            throw new RuntimeException(\"Product ID {$productId} not found.\");\n        }\n\n        $stockStatus = $product->isInStock() ? 'In Stock' : 'OUT OF STOCK';\n\n        echo PHP_EOL . \"=== Product Detail ==\" . PHP_EOL;\n        echo \"Name:   {$product->name}\" . PHP_EOL;\n        echo \"Price:  {$product->getFormattedPrice()}\" . PHP_EOL;\n        echo \"Status: {$stockStatus}\" . PHP_EOL;\n    }\n}\n\n\n// ── index.php (entry point) ───────────────────────────────────────────────────\n// In a real project: require 'vendor/autoload.php'; — that's the only require needed\nuse App\\Repositories\\ProductRepository;\nuse App\\Controllers\\ShopController;\n\n$repository = new ProductRepository();\n$controller = new ShopController($repository);  // inject the dependency\n\n$controller->listInStockProducts();  // list everything in stock\n$controller->showProduct(2);         // show USB-C Hub — which is out of stock",
        "output": "=== In-Stock Products ==\n  [1] Mechanical Keyboard    $129.99 (14 in stock)\n  [3] Monitor Stand          $59.99 (7 in stock)\n\n=== Product Detail ==\nName:   USB-C Hub\nPrice:  $39.99\nStatus: OUT OF STOCK"
      }

Namespace Resolution Order — Why PHP Looks in Your Namespace First (and When That Backfires)

When you reference an unqualified class name like 'Exception' inside a namespace, PHP first checks if that class exists in the current namespace. Only if it doesn't does it fall back to the global namespace. This fallback works for classes but NOT for functions and constants — a difference that has caused countless production bugs.

The rule: inside a namespace: - Unqualified CLASS names: PHP checks current namespace → global namespace - Unqualified FUNCTION names: PHP checks current namespace → NO fallback (before PHP 8.0, it would fallback; in 8.0+ the fallback was removed) - Unqualified CONSTANT names: similar inconsistency

This asymmetry means if your codebase uses a function like 'json_encode()' inside a namespace, it will work as long as no function named 'json_encode' exists in your namespace. But the moment someone adds one — even in a different file — PHP will use that instead of the global version. Hard-to-debug silent failures ensue.

The fix: always prefix global functions with backslash (\json_encode()) or import them explicitly with 'use function json_encode;'. Same for constants with 'use const'. This is defensive coding that prevents an entire class of bugs that only appear after a refactor.

namespace_resolution.phpPHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
namespace App\Utils;

// No import for json_encode
// In PHP >=8.0, this will throw "Call to undefined function App\Utils\json_encode"
// In PHP <8.0, it might work if no local function shadows it

echo json_encode(['test' => 'value']);  // Works in <8.0, fails in >=8.0

// The correct approach:
use function json_encode;  // import the global function explicitly
echo json_encode(['test' => 'value']);  // Works in all versions

// Or for a single use, prefix with backslash:
echo \json_encode(['test' => 'value']);  // Always works

// Constants example:
// Inside a namespace, PHP_EOL refers to App\Utils\PHP_EOL if defined, else global?
// Actually constants follow similar rules - explicit import is safest.
use const PHP_EOL;
echo 'Line ends with' . PHP_EOL;
Output
{"test":"value"}
{"test":"value"}
{"test":"value"}
Line ends with
PHP 8.0+ Strictness
PHP 8.0 removed the fallback for unqualified function calls inside namespaces. If you've upgraded from 7.4 to 8.0 and suddenly get 'undefined function' errors, this is likely the cause. A quick lint with PHPStan level 3 catches these before deployment.
Production Insight
Upgrading from PHP 7.4 to 8.0 broke a production SaaS platform because 32 unqualified function calls relied on the fallback. The error logs showed 'Call to undefined function App\Services\strtolower()'. The fix was automated: a regex pass added backslash prefixes to all global function calls inside namespaces. This took 15 minutes to write but cost 3 hours of incident response.
Rule: run a linting tool (like PHPStan at level 3) after upgrading PHP major versions — it catches these cases before you deploy.
Key Takeaway
Functions and constants do NOT fall back to global namespace — import them or use backslash prefix.
PHP 8.0+ is stricter: no function fallback at all.
Adopt explicit imports as a team standard — it prevents an entire class of bugs.
● Production incidentPOST-MORTEMseverity: high

The Silent Autoload Kill — Namespace Mismatch

Symptom
Fatal error: Class 'App\Services\Logger' not found — even though the file exists and use statement is correct. Autoloader returns null.
Assumption
All use statements are correct and the file path matches the namespace.
Root cause
The composer.json autoload.psr-4 mapping was 'App\' => 'src/app/', but the actual namespace of Logger.php was 'App\Services\Logger' and the file was at 'src/app/Services/Logger.php'. However, a copy of the file existed in another directory with wrong namespace, and Composer's optimised autoloader cached the wrong path.
Fix
Run 'composer dump-autoload' to regenerate the classmap. Then verify the file path and namespace match exactly. Use 'composer dump-autoload -o' for optimised classmaps to catch mismatches during development.
Key lesson
  • Always run composer dump-autoload after moving or renaming namespace files.
  • Include a sanity check in CI: a simple script that tries to instantiate each major service class.
  • PSR-4 is strict: a single character mismatch (uppercase vs lowercase) breaks autoloading silently.
Production debug guideSymptom → Action guide for common PHP namespace problems4 entries
Symptom · 01
Class not found despite correct use statement
Fix
Check that the file exists at the path matching namespace. Run 'composer dump-autoload'. Verify composer.json psr-4 mapping.
Symptom · 02
Cannot use X as X because the name is already in use
Fix
Add an alias: 'use Foo\Bar as FooBar'. You have two classes with the same short name from different namespaces.
Symptom · 03
Call to undefined function str_replace() inside a namespace
Fix
Global functions are not automatically imported. Either add 'use function str_replace;' or prefix with backslash: \str_replace().
Symptom · 04
Namespace declaration must be the first statement in the script
Fix
Remove any HTML output, echo, or require statements before the 'namespace' keyword. Only 'declare(strict_types=1)' is allowed before it.
★ PHP Namespace Debug Cheat SheetQuick commands and checks for resolving namespace and autoloading issues
Class not found after adding new file
Immediate action
Generate fresh autoloader
Commands
composer dump-autoload
php -r "require 'vendor/autoload.php'; echo class_exists('App\Services\PaymentGateway');"
Fix now
Ensure file is in the correct directory and namespace matches exactly (case-sensitive on Linux).
use statement causes error 'already in use'+
Immediate action
Check for duplicate class names in imported namespaces
Commands
grep -r '^use.*Logger' src/
php -r "echo (new ReflectionClass('Monolog\Logger'))->getFileName();"
Fix now
Add an explicit alias: 'use Monolog\Logger as MonologLogger;'
AspectNo Namespaces (Old Style)With Namespaces (PSR-4)
Class namingVendor_Package_ClassName (manual prefix)ClassName inside namespace App\Package
Name collision riskHigh — developer manually ensures uniquenessEliminated — fully-qualified names are unique
ReadabilityClass names become sentencesShort, clean class names with imports at top
AutoloadingRequires manual require/include chainsComposer maps namespace to directory automatically
Refactoring classesMust rename every prefix occurrence manuallyMove file + update namespace declaration only
Third-party librariesRisky — any shared name causes fatal errorSafe — each vendor owns its namespace prefix
IDE supportLimited autocomplete without clear structureFull autocomplete and go-to-definition support

Key takeaways

1
A namespace is a named container for classes
it makes 'App\Logger' and 'Monolog\Logger' two completely different identities, even though both files define a class called 'Logger'.
2
'use' is an alias declaration only
it does not load any file. Autoloading is triggered by instantiation, not by the 'use' statement.
3
PSR-4 creates a contract
namespace prefix maps to a base directory, so 'App\Services\PaymentGateway' must live at 'src/Services/PaymentGateway.php'. One namespace per file, mirror the directory structure.
4
Inside a namespace, always import global PHP classes explicitly ('use DateTime;' or 'new \DateTime()')
don't rely on implicit fallback. Functions inside namespaces don't follow the same fallback rules as classes, making implicit reliance a source of hard-to-spot bugs.
5
Always run 'composer dump-autoload' after moving files or adjusting namespace declarations. Include a CI check for namespace-to-path consistency.
6
PHP 8.0+ removed the function fallback
use explicit imports or backslash prefixes for all global function calls inside namespaces.

Common mistakes to avoid

3 patterns
×

Putting code before the namespace declaration

Symptom
PHP throws 'Namespace declaration statement has to be the very first statement in the script'
Fix
Make 'namespace' the first line (or second, after 'declare(strict_types=1)'). No HTML, no echo, no require before it.
×

Expecting 'use' to autoload the class

Symptom
Writing 'use App\Services\Mailer' and then getting 'Class not found'
Fix
'use' is only an alias. The file still needs to be loaded, either by Composer's autoloader (require 'vendor/autoload.php' in your entry point) or a manual require. The 'use' statement doesn't trigger either.
×

Forgetting to import global PHP classes inside a namespace

Symptom
Writing 'new DateTime()' inside 'namespace App\Services' and getting 'Class App\Services\DateTime not found'
Fix
Add 'use DateTime;' at the top of the file, or prefix it as 'new \DateTime()'. PHP looks in the current namespace first for classes, and the fallback to global isn't guaranteed to be obvious when the error fires.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
What is the difference between a fully-qualified class name, a qualified...
Q02SENIOR
How do PHP namespaces and PSR-4 autoloading work together? Could you set...
Q03JUNIOR
If you have two classes both named 'Collection' from different vendor pa...
Q04SENIOR
How can you use namespaces with PHP functions and constants? What change...
Q01 of 04SENIOR

What is the difference between a fully-qualified class name, a qualified class name, and an unqualified class name in PHP namespaces — and when does PHP resolve each one?

ANSWER
A fully-qualified class name (FQCN) starts with a backslash, e.g., '\App\Services\Logger'. It is absolute and always refers to the same class. A qualified class name includes part of the namespace, e.g., 'Services\Logger' inside the 'App' namespace. PHP resolves it by prepending the current namespace. An unqualified class name has no namespace prefix, e.g., 'Logger'. Inside a namespace, PHP first looks in the current namespace, then falls back to the global namespace for classes (but not for functions/constants in PHP 8+). At the global level, an unqualified name resolves directly to the global namespace. Understanding this resolution order is critical for debugging 'class not found' errors.
FAQ · 5 QUESTIONS

Frequently Asked Questions

01
Can I declare multiple namespaces in one PHP file?
02
Do PHP namespaces affect performance?
03
What's the difference between 'use App\Logger' and 'use App\Logger as Logger'?
04
Can I import functions and constants with 'use'?
05
How do I resolve 'Cannot use X as X because the name is already in use'?
🔥

That's OOP in PHP. Mark it forged?

5 min read · try the examples if you haven't

Previous
Traits in PHP
5 / 7 · OOP in PHP
Next
Static Methods and Properties in PHP