How to Organize External Modules Without Namespaces: Beyond the Candy Cup Analogy?

How to Organize External Modules without Namespaces

The Problem with Namespaces

Namespaces seem like a natural fit for organizing types in external modules, but they introduce several limitations:

• Namespace pollution: Each module creates its own namespace, making it difficult to find and reuse types across modules.
• Name collisions: If two modules define types with the same name, the namespace doesn't prevent collisions, and the compiler will report an error.
• Excessive nesting: Using namespaces in modules leads to a cluttered structure with multiple levels of nesting.

The Candy Cup Analogy

Imagine using a separate cup for each type of candy (e.g., Twix, PeanutButterCup). This approach is inefficient because you end up with multiple cups, and it's not clear how the candies are related.

Instead, it's better to organize the candies based on their file system location, similar to how modules are organized within a project.

Key Principles for Organizing Modules

• Export as close to the top level as possible:

  • Use export default for single classes or functions, making them directly accessible to consumers.
  • For multiple exports, use top-level declarations.

• Use modules/namespaces sparingly:

  • Only use export namespace/module for large or complex modules with numerous exports.

Red Flags

• A file containing only export module Foo { ... }
• A file with a single non-default export class or export function
• Multiple files with the same export module Foo { ... } (they won't combine)

The above is the detailed content of How to Organize External Modules Without Namespaces: Beyond the Candy Cup Analogy?. For more information, please follow other related articles on the PHP Chinese website!