std/lib: for php

Overview

std/lib is a very ambitious project.

std/lib is a set of libraries, meant to primarily be implemented in PHP to solve many problems of general PHP development and within the PHP ecosystem.

std/lib is not a framework. It is a set of common APIs to solve common problems faced by PHP developers in a vendor-neutral, framework-neutral way.

std/lib SHALL NOT CREATE IMPLEMENTATIONS OF FUNTIONALITY ITSELF, UNLESS ABSOLUTELY REQUIRED TO DO SO.

Priorities to implementation of wrappers will be where PHP suffers the most: Process Control, Threading, Asynchronous Execution, Error Handling, and functionality you would expect to find in a “standard runtime library”.

Goals

Instead of re-implementing things that already exist, std/lib is here to:

  • Provide wrappers around standard PHP functionality, well-known, and lesser-known libraries/frameworks/functionality:

    These may be fairly transparent wrappers (Std\Redis\Client is basically the same as predis, just with an adapter interface to use a different implementation)

    These may be as more complex anti-corruption layers which improve/hide poorly exposed but well implemented libraries.

    These may be facades, which simplify complex operations.

  • Provide bridges in/out of various existing frameworks.

    While this is improving with PSR-x standards, it's still a big giant mess if you want to use more than one framework, parts from different frameworks, parts from framework-independent libraries, or any mix of the three.

  • Help standardize things

    The hope here is that by supporting many library implementations with quality APIs, as well as quality wrappers around base functionality that it will become a de-facto standard of how to access X.

Again, primitive functionality aside (string/array type low-level functionality -- or "glue" for cross-library/framework libraries) this is NOT an attempt to re-implement any functionality.

Guarantees

The purpose is only to provide existing implementations wrapped in a type-safe and strict API. Additionally, unless clearly specified otherwise, stable releases MUST provide the following objective guarantees:

  • Generally, independent of php extensions installed. See Extensions
  • No PHP-level E_* notices, warnings, or errors. Only exceptions are thrown in error situations.
  • No "mixed" return types or parameters - except in those that are for the normalization or determination of values and types, or for development.
  • No globally namespaced functions or classes.

This list is expected to expand.

We also hope to provide the following subjective guarantees:

  • A stable, well thought-out exception tree.
  • The best "backend" implementation by default. Zend, Symfony, Laravel, League, Cake, Concrete, or "other" framework-independent implementation -- we have no bias, only bias twoards well-written code.
  • Through various bridges, providing all frameworks with implementations of "mission critical" quality code.

Wrappers

Standard library implementations will, in order of preference:

  • Compose new classes (composition) with underlying implementations passed-in with dependency injection, with the “preferred” implementation auto-injected. (alternatively, create internally if absolutely necessary)
  • Inherit underlying implementations where it must be done, i.e, adapters. Multiple adapters that inherit different implementations MAY be provided as separate packages (i.e, adapter for Zend, adapter for Symfony, etc).
  • Fork project(s) and provide slightly modified versions of packages, keeping it up-to-date with the upstream version where absolutely necessary.
  • Implement it ourselves, as a final resort.

Planned Namespace Use

Example:

  • std\ namespace for generics.
  • stdlib\ namesapce for implementations.
  • std\NetUtil for basic utilities.
  • stdlib\Net\Server for full implementations.

Next Steps

ALL CODE IS SUBJECT TO CHANGE AT PRESENT. Currently, std/lib is in very early stages of development. Until the 1.0 release, anything is subject to change.

  • [ ] Which libraries are most important from the Library Wish List? - Put into a fully prioritized list.
  • [ ] What is the best way to organize the base array, string, and low-level utility functionality?
  • [ ] Are there other guarantees we should consider?
  • [ ] Begin implementation
    • [ ] Implement “base” library - strings, array, value validation, and other core functions.
    • [ ] Implement app-* libaries.
    • [ ] (Expand out to top 3 priorities in Wish List)
  • [ ] Are there other well known frameworks we should consider full or partial compatibility with?
  • [ ] What is the minimum quality that will be acceptable for stable releases?
  • [ ] What is the minimum quality that will be acceptable for development releases?
  • [ ] Get public feedback
  • [ ] Get public interest
  • [ ] Does BSD vs MIT licensing really matter?
  • [ ] Why is Rust, for example, licensed under Apache 2 as well as BSD (or MIT?)