DEV Community: Maksim Epikhin

The Laravel Idea Plugin is Now Free for PhpStorm Users

Maksim Epikhin — Thu, 31 Jul 2025 08:13:56 +0000

Starting July 30, 2025, the Laravel Idea plugin will be free for PhpStorm users. If you already have it installed, you’ll get full access to all features at no extra cost.

Laravel Idea is a smart Laravel development environment built on PhpStorm. Developed by Adel Faizrakhmanov, the plugin has been downloaded over 1.5 million times from the JetBrains Marketplace and is highly regarded by Laravel developers. It enhances PhpStorm’s native Laravel support with powerful productivity-boosting tools, including:

Intelligent code generation.
Advanced autocompletion for routes, validation, request fields, policies, configs, translations, views, and more.
Deep Eloquent ORM understanding.
Full Blade component support.
Seamless integration with Livewire, Inertia.js, Dusk, Laravel Modules, and other third-party packages

To install the Laravel Idea plugin in PhpStorm, go to Settings | Plugins and search for the plugin in the Marketplace tab.

Source link: The Laravel Idea Plugin is Now Free for PhpStorm Users

PHP 8.5: New array functions. array_first() and array_last()

Maksim Epikhin — Sun, 06 Jul 2025 21:23:01 +0000

PHP RFC: array_first() and array_last()

Version: 1.0
Date: 2025-03-31
Author: Niels Dossche, nielsdos@php.net
Status: Implemented
Target Version: 8.5
Implementation: https://github.com/php/php-src/commit/168343d2e811fe0f2152d39a8f88557cc0b35c86
First Published at: https://wiki.php.net/rfc/array_first_last

Introduction

In PHP 7.3, we got array_key_first() and array_key_last() to get the first and last keys from an array. What we don't have yet is a way to get the first and last values of an array. This is harder than you may think because:

The array keys are not necessarily integers, not necessarily starting with 0, etc...
Existing "tricks" like reset() and end() are semantically the wrong approach because they modify the "internal iterator" of the array. Furthermore, it also does not work properly on all types of expressions (e.g. an array returned from a function / plain array can cause a notice due to the by-ref argument).
Using ''$array[array_key_first($array)]'' is cumbersome

Proposal

function array_first(array $array): mixed {}
function array_last(array $array): mixed {}

These functions return the first/last value of the array, respectively. I.e. these functions are equivalent to ''$array[array_key_first($array)]'' and similarly for the last element. Alternatively, for array_first(), this could be written as a foreach loop where the first iteration returns.

If the array value to be returned is a reference, it is dereferenced automatically.

Behaviour on empty arrays

https://wiki.php.net/rfc/array_key_first_last also proposed to implement these functions, but the vote for those failed. The main complaint seemed to be the behaviour on failure.

Should it throw on an empty array or should it return NULL?
Theoretically NULL can be a valid value from an array, and therefore returning NULL does not allow distinguishing between an empty array and a NULL value. However, there are still strong arguments in favor of using NULL:

Consistent with ''$array[array_key_first($array)]'', i.e. accessing a non-existent key gives NULL
Consistent with ''array_find($arr, fn () => true)'' returning NULL on no match
Consistent with ''array_shift()'' and ''array_pop()'' returning NULL on empty arrays (also about retrieving first/last element, but with modification)
Consistent with common framework helpers like ''Arr::first()''
NULL is a rare legitimate value, so the potential for clashing is low
Works nicely with "??" operator
If it were to throw an exception instead, then you would need to check the size of the array upfront. Similarly, if NULL is a legit value then you can just check the array size upfront too.

Another interesting idea is to add an optional "$default" argument (i.e. if provided return the default; otherwise throw). However, since PHP arrays are untyped it's often hard to define something meaningful as a sentinel value. There is also no precedent for this design choice for the array functions. Furthermore, when a programmer reads ''array_first($somevar, $someothervar)'', it looks weird unless you already know that ''$somevar'' is an array and ''$someothervar'' is a fallback value. It just looks unintuitive.

Naming

Why array_first/array_last instead of array_value_first/array_value_last?
First, this is consistent with how (most) array functions are named: the ones that work on keys have "key" in the name, and the ones that work on values don't have "value" in the name. Think about array_find, array_find_key, etc.
Second, the shorter name is less verbose and intuitively at least I understood this is about the value.

Fibers

In the https://externals.io/message/121313 there was some confusion on how this interacted with Fibers. TL;DR: The concern was that if you have a call for array_key_first() followed by array_first() that the result could be inconsistent if a Fiber interrupted the execution. This is however based on the false premise that Fibers are threads, in fact they are not. This situation cannot happen.

Why include this in the engine rather than userland?

Three main reasons:

Consistency with array_key_first()/array_key_last().
The cost/maintenance burden is practically zero, the implementation is stupidly simple (4 lines trivial argument parsing boilerplate, 3 lines actual code; per function).
Very fast implementation, faster than a PHP implementation in my brief tests. Further optimization is possible by implementing an additional frameless variant, but that's future material if ever necessary/interesting.

Examples

Here are some code examples of how to use these functions:

array_first(["single element"]); // "single element"
array_last(["single element"]); // "single element"

array_first([]); // NULL
array_last([]); // NULL

array_first([1 => 'a', 0 => 'b', 3 => 'c', 2 => 'd']); // 'a'
array_last([1 => 'a', 0 => 'b', 3 => 'c', 2 => 'd']); // 'd'

$str = "hello";
array_first([&$str, false]); // "hello" (no ref)
array_last([false, &$str]); // "hello" (no ref)

Backward Incompatible Changes

If anyone defined array_first() or array_last() in their global scope, then they need to guard it now with function_exists or throw it away because of the name clash. Although it should be noted that the global namespace is normally reserved for PHP's usage.

Proposed PHP Version(s)

Next PHP 8.x, i.e. PHP 8.5 at the time of writing.

Patches and Tests

PR: https://github.com/php/php-src/pull/18210

Implementation

After the project is implemented, this section should contain

the version(s) it was merged into: 8.5
a link to the git commit(s): https://github.com/php/php-src/commit/168343d2e811fe0f2152d39a8f88557cc0b35c86
a link to the PHP manual entry for the feature: TBD
a link to the language specification section (if any): N/A

References

Current discussion: https://externals.io/message/127047

Prior Work

Proposal from 2023 discussing these new functions: https://externals.io/message/121313
RFC that introduced array_key_first() and array_key_last(): https://wiki.php.net/rfc/array_key_first_last with discussion: https://externals.io/message/102663

PHP 8.5 Pipe operator v3

Maksim Epikhin — Fri, 04 Jul 2025 09:19:01 +0000

PHP https://wiki.php.net/rfc/ Pipe operator v3

Version: 0.9
Date: 2025-02-05
Author: Larry Garfield (larry@garfieldtech.com)
Status: Implemented
Target version: PHP 8.5
First Published at: http://wiki.php.net/rfc/pipe-operator-v3
Implementation: https://github.com/php/php-src/commit/1c09c0c8323342aaaecbe444b3afa45efbd72ced

Introduction

In object-oriented code, "composition" generally means "one object having a reference to another." In functional programming, "composition" generally means "sticking two functions together end-to-end to make a new function." Both are valid and useful techniques, especially in a multi-paradigm language like PHP.

Composition generally takes two forms: Immediate and delayed. The immediate execution of chained functions is typically implemented with a "pipe" operator. Delayed execution is typically implemented with a composition operator, which takes two functions and produces a new function that will call each one in turn. The combination of the two cleanly enables “point-free style,” an approach to programming that limits the use of unnecessary intermediary variables. Point-free style has been gaining popularity in JavaScript circles, so will be familiar to JavaScript developers using that style.

This RFC introduces the "pipe" operator, in the form used by most other languages with such functionality. A function composition operator is saved for a follow up RFC. (See Future Scope.)

For example:

function getUsers(): array {
    return [
        new User('root', isAdmin: true),
        new User('john.doe', isAdmin: false),
    ];
}

function isAdmin(User $user): bool {
    return $user->isAdmin;
}

// This is the new syntax.
$numberOfAdmins = getUsers()
    |> fn ($list) => array_filter($list, isAdmin(...)) 
    |> count(...);

var_dump($numberOfAdmins); // int(1);

Proposal

This RFC introduces a new operator:

mixed |> callable;

The ''|>'' operator, or "pipe," accepts a single-parameter callable on the right and passes the left-side value to it, evaluating to the callable's result.

Pipe (''|>'') evaluates left to right by passing the value (or expression result) on the left as the first and only parameter to the callable on the right. That is, the following two code fragments are logically equivalent:

$result = "Hello World" |> strlen(...);

$result = strlen("Hello World");

For a single call that is not especially useful. It becomes useful when multiple calls are chained together. That is, the following two code fragments are effectively equivalent:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

$temp = "Hello World";
$temp = htmlentities($temp);
$temp = str_split($temp);
$temp = array_map(strtoupper(...), $temp);
$temp = array_filter($temp, fn($v) => $v != 'O');
$result = $temp;

The left-hand side of the pipe may be any value or expression. The right-hand side may be any valid PHP callable that takes a single parameter, or any expression that evaluates to such a callable. Functions with more than one required parameter are not allowed and will fail as if the function were called normally with insufficient arguments. If the right-hand side does not evaluate to a valid callable it will throw an Error.

A pipe chain is an expression, and therefore may be used anywhere an expression is valid.

Precedence

The pipe operator is left-associative. The left side will be evaluated first, before the right side.

The pipe operator precedence has been selected around expected common use cases. In particular, it binds before comparison operations so that its result may be compared, but after mathematical operations. If appropriate, parentheses can be added around any set of operations to alter or clarify the precedence, just like any other expression.


// These are equivalent.
$res1 = 5 + 2 |>  someFunc(...);
$res1 = (5 + 2) |>  someFunc(...);

// The result of the pipe chain is compared against 4.
$res1 = 'beep' |> strlen(...) == 4;

// The pipe executes before the ??, so the 
// default value applies to the result of the whole chain.
$user = $id
     |> get_username(...)
     ?? 'default';

// This requires parens
$res1 = 5 |> ($user_specified_func ?? defaultFunc(...));

// This requires parens to allow the 
// ternary to run first and select the callable to use.
$res1 = 5 |> ($config['flag'] ? enabledFunc(...) : disabledFunc(...));

Performance

The current implementation works entirely at the compiler level, and effectively transforms the first example above into the second at compile time. The result is that pipe itself has virtually no runtime overhead. (Any additional closures created by the user while writing a pipe will of course have their own overhead.)

More precisely, the implementation contains 3 optimizations, for a function-style, method-style, or static method style first-class-callable. Those will be compiled down to direct calls, and therefore have no performance overhead. An arbitrary expression will be evaluated and then executed, with no additional overhead. However, that arbitrary expression may have additional logic in it to support a pipe that cannot be compiled away. For example, an inline arrow function that simply forwards the call is not detectable, so the extra arrow function cannot be optimized away.

That means the above example would more precisely compile to:

$temp = "Hello World";
$temp = htmlentities($temp);
$temp = str_split($temp);
$temp = fn($x) => array_map(strtoupper(...), $x)($temp);
$temp = fn($x) => array_filter($x, fn($v) => $v != 'O')($temp);
$result = $temp;

That gives a little overhead over making all calls directly, but only in some cases, and not dramatically so.

Should the proposed follow-up RFC of Partial Function Application RFC (see below) be approved, it would be logical and recommended for a similar optimization to be made when a PFA appears on the right-side of pipe. That would eliminate most common uses of a wrapping closure as well.

Callable styles

Pipe supports any callable syntax supported by PHP. At present, the most common form is first-class-callables (eg, ''strlen(...)''), which dovetails with this syntax very cleanly. Should further improvements be made in the future, such as a revised Partial Function Application RFC, it would be supported naturally.

References

As usual, references are an issue. Supporting pass-by-ref parameters in simple cases is quite easy, and a naive implementation would support it. However, passing a value from a compound value (an object property or array element) by reference does not work, and throws an "Argument could not be passed by reference" error. In practice, it is easier to forbid pass-by-ref parameters in pipe than to allow them.

$arr = ['a' => 'A', 'b' => 'B'];

$val = 'C';

function inc_print(&$v) {
  $v++;
  print $v;
}

// This can be made to work.
$val |> inc_print(...);

// This cannot be easily made to work, and it might not even be possible.
$arr |> inc_print(...);

That is also consistent with the typical usage patterns. The whole design of the pipe operator is that data flows through it from left to right, in pure-functional way. Passing by reference would introduce all sorts of potential "spooky action at a distance." In practice, there are few if any use cases where it would be appropriate to do in the first place.

For that reason, pass-by-ref callables are disallowed on the right-hand side of a pipe operator. That is, both examples above would error.

One exception to this is "prefer-ref" functions, which only exist in the stdlib and cannot be implemented in user-space. There are a small handful of functions that will accept either a reference or a direct value, and vary their behavior depending on which they get. When those functions are used with the pipe operator, the value will be passed by value, and the function will behave accordingly.

Syntax choice

F#, discussion in JavaScript about adding a ''|>'' operator as described here. It is the standard operator for this task.

Use cases

The use cases for a pipe operator are varied. They include, among others, encouraging shallow-function-nesting, encouraging pure functions, expressing a complex process in a single expression, and emulating extension functions.

The following examples are all simplified from real-world use cases in code I have written.

String manipulation

// Simplified version.  The original code this is
// based on splits a string at _ and capitals, too, but
// that is omitted to focus on the core point.
function splitString(string $input): array
{
    return explode(' ', $input);
}

// Convert a string to snake_case

$result = 'Fred Flintstone'
    |> splitString(...)           // Produces an array of individual words.
    |> fn($x) => implode('_', $x) // Join those words with _
    |> strtolower(...)            // Lowercase everything.
;

// $result is 'fred_flintstone'

// Convert a string to lowerCamelCase

$result = 'Fred Flintstone'
    |> splitString(...),
    |> fn($x) => array_map(ucfirst(...), $x)  // Uppercase the first letter of each word
    |> fn($x) => implode('', $x)              // Join those words
    |> lcfirst(...)                           // Now lowercase just the first letter
;

// $result is 'fredFlintstone'

Array combination


$arr = [
  new Widget(tags: ['a', 'b', 'c']),
  new Widget(tags: ['c', 'd', 'e']),
  new Widget(tags: ['x', 'y', 'a']),
];

$result = $arr
    |> fn($x) => array_column($x, 'tags') // Gets an array of arrays
    |> fn($x) => array_merge(...$x)       // Flatten that array into one big array
    |> array_unique(...)                  // Remove duplicates
    |> array_values(...)                  // Reindex the array.
;

// $result is ['a', 'b', 'c', 'd', 'e', 'x', 'y'. 'z']

The single-expression alternative today would be:

array_values(array_unique(array_merge(...array_column($arr, 'tags'))));

Which I believe is indisputably worse.

Shallow calls

The use of a pipe for function composition also helps to separate closely related tasks so they can be developed and tested in isolation. For a (slightly) contrived and simple example, consider:

function loadWidget($id): Widget
{
    $record = DB::query("something");
    return makeWidget($record);
}

function loadMany(array $ids): array
{
    $data = DB::query("something");
    $ret = [];
    foreach ($data as $record) {
        $ret[] = $this->makeWidget($record);
    }
    return $ret;
}

function makeWidget(array $record): Widget
    // Assume this is more complicated.
    return new Widget(...$record);
}

In this code, it is impossible to test ''loadWidget()'' or ''loadMany()'' without also executing ''makeWidget()''. While in this trivial example that's not a huge problem, in a more complex example it often is, especially if several functions/methods are nested more deeply. Dependency injection cannot fully solve this problem, unless each step is in a separate injected class.

By making it easy to chain functions together, however, that can be rebuilt like this:

function loadWidget($id): array
{
    return DB::query("something");
}

function loadMany(array $ids): array
{
    return DB::query("something else");
}

function makeWidget(array $record): Widget
    // Assume this is more complicated.
    return new Widget(...$record);
}

$widget = loadWidget(5) |> makeWidget(...);

$widgets = [1, 4, 5] 
    |> loadMany(...) 
    |> fn(array $records) => array_map(makeWidget(...), $records);

And the latter could be further simplified with either a higher-order function or partial function application. Those chains could also be wrapped up into their own functions/methods for trivial reuse. They can also be extended, too. For instance, the result of ''loadMany()'' is most likely going to be used in a ''foreach()'' loop. That's a simple further step in the chain.

$profit = [1, 4, 5] 
    |> loadMany(...)
    |> fn(array $records) => array_map(makeWidget(...), $records)
    |> fn(array $ws) => array_filter(isOnSale(...), $ws)
    |> fn(array $ws) => array_map(sellWidget(...), $ws)
    |> array_sum(...);

Moreover, because a pipe can take any callable, a pipe chain can be easily packaged up, either as a named function or anon function.

// This would be the "real" API that most code uses.
function loadSeveral($id) {
  return $id 
      |> loadMany(...) 
      |> fn(array $records) => array_map(makeWidget(...), $records);
}

$profit = [1, 4, 5] 
    |> loadSeveral(...)
    |> fn(array $ws) => array_filter(isOnSale(...), $ws)
    |> fn(array $ws) => array_map(sellWidget(...), $ws)
    |> array_sum(...);

That neatly encapsulates the entire logic flow of a process in a clear, compact, highly-testable set of operations.

Pseudo-extension functions

"Extension functions" are a feature of Kotlin and C# (and possibly other languages) that allow for a function to act as though it is a method of another object. It has only public-read access, but has the ergonomics of a method. While not a perfect substitute, pipes do offer similar capability with a little more work.

For instance, we could easily make utility higher-order functions (functions that take or return other functions/callables) that will map or filter an array that is piped to them. (A more robust version that also handles iterables is only slightly more work.)

function amap(callable $c): \Closure
{
    return fn(array $a) => array_map($c, $a);
}

function afilter(callable $c): \Closure
{
    return fn(array $a) => array_filter($a, $c);
}

That allows them to be used, via pipes, in a manner similar to "scalar methods." To reuse the earlier example:

$profit = [1, 4, 5] 
    |> loadSeveral(...)
    |> afilter(isOnSale(...))
    |> amap(sellWidget(...))
    |> array_sum(...);

Which is not far off from what it would look like with scalar methods, which still wouldn't work if any step along the way contained an object:

$profit = [1, 4, 5] 
    ->loadSeveral(...)
    ->afilter(isOnSale(...))
    ->amap(sellWidget(...))
    ->sum(...);

But can work with //any// value type, object or scalar. It also entirely removes the "does the subject come first or last" question: the subject is //piped//, and the arguments to the higher-order function are the modifiers. It also eliminates the need to discuss which methods deserve to be "first class" operations that turn into methods. Any function can be chained onto a value of any type.

While I do not believe pipes can completely replace extension functions, they provide a reasonable emulation and most of the benefits, for trivial cost.

This RFC does not propose any such higher-order functions for the PHP standard library, as most are quite easy to implement in user space. However, such could be easily added in the future if desired for especially common cases.

Single-expression pipelines

Of particular note, all of the above examples are a single expression. That makes them trivial to use in places where only a single-expression is allowed, such as ''match()'' arms, short-get property hooks, short-closures, etc. For example:


$string = 'something GoesHERE';

$newString = match ($format) {
    'snake_case' => $string
        |> splitString(...)
        |> fn($x) => implode('_', $x)
        |> strtolower(...),
    'lowerCamel' => $string
        |> splitString(...),
        |> fn($x) => array_map(ucfirst(...), $x)
        |> fn($x) => implode('', $x)
        |> lcfirst(...),
    // Other case options here.
};

class BunchOfTags
{
    private array $widgets = [];

    public array $tags {
        get => $this->widgets
            |> fn($x) => array_column($x, 'tags')
            |> fn($x) => array_merge(...$x)
            |> array_unique(...)
            |> array_values(...);
    }
}

$loadSeveral = fn($id) => $id 
      |> loadMany(...) 
      |> fn(array $records) => array_map(makeWidget(...), $records);

Streams

Similarly, a few small utility functions (either in C or PHP) would allow pipes to be used with stream resources. As a simplified example:

function decode_rot13($fp): \Generator
{
    while ($c = fgetc($fp)) {
        yield str_rot13($c);
    }
}

// Takes an iterable of strings and returns a line-buffering version of it.
// A more robust version is of course possible, but longer.
function lines_from_charstream(iterable $it): \Closure
{
    $buffer = '';
    return static function () use ($it, &$buffer) {
        foreach ($it as $c) {
            $buffer .= $c;
            while (($pos = strpos($buffer, PHP_EOL)) !== false) {
                yield substr($buffer, 0, $pos);
                $buffer = substr($buffer, $pos);
            }
        }
    };
}


fopen('pipes.md', 'rb') // No variable, so it will close automatically when GCed.
    |> decode_rot13(...)
    |> lines_from_charstream(...)
    |> map(str_getcsv(...))
    |> map(Product::create(...))
    |> map($repo->save(...))
;

This is just a demonstration of the potential, not a recommendation for a specific API. But hopefully it shows the potential for making working with streams in a structured way vastly easier, in a way found in a number of languages.

Existing implementations

Multiple user-space libraries exist in PHP that attempt to replicate pipe-like or compose-like behavior. All are clunky and complex by necessity compared to a native solution. There is clear demand for this functionality, but user-space's ability to provide it is currently limited. This list has only grown since the Pipes v2 RFC, indicating an even stronger benefit to the PHP ecosystem with a solid built-in composition syntax.

The PHP League has a Pipeline library that encourages wrapping all functions into classes with an ''%%__invoke()%%'' method to allow them to be referenced, and using a ''->pipe()'' call for each step.
Laravel includes a even more cumbersome syntax.
The pipe function, though it is more of a function concatenation operation.
Sebastiaan Luca has a pipe library that works through abuse of the ''%%__call%%'' method. It only works for named functions, I believe, not for arbitrary callables.
PipePie is another very similar implementation to the previous ones.
ZenPipe is a new-comer that also uses a method named ''pipe()'' for what is actually a composition operation.
Crell/fp provides ''pipe()'' and ''compose()'' functions that take an array of callables. While the lightest-weight option on this list, that makes dynamically-built pipelines or compositions more cumbersome than the syntax proposed here.
Various blogs speak of "the Pipeline Pattern" (for example), or more recently, Creating a type-safe pipe() in PHP

Those libraries would be mostly obsoleted by this RFC (in combination with the compose follow on, as noted in future-scope), with a more compact, more universal, better-performing syntax.

Why in the engine?

The biggest limitation of any user-space implementation is performance. Even the most minimal implementation (Crell/fp) requires adding 2-3 function calls to every operation, which is relatively expensive in PHP. A native implementation would not have that additional overhead. Crell/fp also results in somewhat awkward function nesting, like this:

pipe($someVal,
    htmlentities(...),
    str_split(...),
    fn($x) => array_map(strtoupper(...), $x),
    fn($x) => array_filter($x, fn($v) => $v != 'O'),
);

// (Or worse if you need conditional stages.)

Compared to the compiled version, this has two extra wrapping closures (for ''htmlentities()'' and ''str_split()'') that could not be compiled away, the call to ''pipe()'' itself, and a foreach loop inside pipe. All of those are eliminated with a native operator. As noted above, PFA would also allow eliminating the two manual closures via compiler optimization, something a user-space implementation would never be able to do.

More elaborate implementations tend to involve magic methods (which are substantially slower than normal function/method calls) or multi-layer middlewares, which are severe overkill for sticking two functions together.

Additionally, a native operator would make it much easier for static analysis tools to ensure compatible types. The SA tools would know the input value's type, in most cases the callable type on the RHS, and could compare them directly without several layers of obfuscated user-space function calls between them.

Future Scope

This RFC is deliberately "step 1" of several closely related features to make composition-based code easier and more ergonomic. It offers benefit on its own, but deliberately dovetails with several other features that are worthy of their own RFCs.

Language features

A compose operator for closures (likely ''+''). Where pipe executes immediately, compose creates a new callable (Closure) that composes two or more other Closures. That allows a new operation to be defined simply and easily and then saved for later in a variable. Because it is "just" an operator, it is compatible with all other language features. That means, for example, conditionally building up a pipeline is just a matter of throwing ''if'' statements around as appropriate. The author firmly believes that a compose operator is a necessary companion to pipe, and the functionality will be incomplete without it. However, while pipe can be implemented trivially in the compile step, a compose operator will require non-trivial runtime work. For that reason it has been split out to its own RFC.

General partial function application. While the prior RFC was declined due to its perceived use cases being insufficient to justify its complexity, there was clear interest in it, and it would vastly improve the usability of function composition. If a less complex implementation can be found, it would most likely pass and complement this RFC well.

A "close but accept object" symbol. Currently, it's not convenient to call a method on an object returned in a pipe step without wrapping it into a closure, like so:

$obj |> fn($x) => $x->foo(4, 5);

One possible alternative would be a syntax such as $$->foo(4, 5), which would be logically equivalent to the above. That would also work for properties, allowing easy reading or writing of "the object in question." It's likely we could optimize that syntax away the same way FCCs are in this RFC.

A ''%%__bind%%'' method or similar on objects, possibly with a dedicated operator of its own (such as ''>>=''). If implemented by an object on the left-hand side, the right-hand side would be passed to that method to invoke as it sees fit. Such a feature would be sufficient to support arbitrary monadic behavior in PHP in a type-friendly way.

Iterable API

There has been on-again-off-again discussion of a new iterable API for some time, one that could replace ''array_map()'', etc. with a more ergonomic, iterator-friendly API. Pipes are a natural fit for that.

Consider the case of having reimplemented ''iter\map()'', ''iter\filter()'', ''iter\first()'', ''iter\unique()'', and so on, in C. Such functions could be written to accept both arrays and iterables, and to return the same type they were given. Combined with Partial Application, that would lead to:

$result = $pdo->query("Some complex SQL")
    |> filter(?, someFilter(...))
    |> map(?, transformer(...))
    |> unique(...)
    |> first(someCriteria(...));

There are likely other optimizations that a C implementation could make. All functions would be both pipe-friendly and usable stand-alone.

An iterable API is not included in this RFC, but this RFC would make implementing one in a fully flexible way substantially easier.

Rejected Features

There was discussion both on-list and off of "auto-partialling" functions after a pipe, such that the operand value is always passed as the first argument of the right side function. That would allow functions to be written in a "pipe friendly" way by assuming subject-first, and then would not need Partial Application or a wrapping closure in order to provide additional arguments. This is the way Elixir works, for instance. For example:


// This RFC today
$foo
  |> bar(...)
  |> fn($x) => array_filter($x, fn($v) => $v != 'O');

// If PFA passes:
$foo
  |> bar(...)
  |> array_filter(?, fn($v) => $v != 'O');

// With Elixir style
$foo
  |> bar()
  |> array_filter(fn($v) => $v != 'O');

(The use of expressions on the RHS would be supported by wrapping them in parens, to indicate "don't auto-partial.")

While the author found that compelling, several commenters felt it would be too surprising and unexpected for developers. For that reason, it has been left out of this RFC. It would be possible to add support in the future, but only if the auto-partialling became "opt in" with some additional syntax rather than "opt out." (Like ''$foo |> @array_filter(fn($v) => $v != 'O')'' or something like that.)

Backward Incompatible Changes

None

Proposed PHP Version(s)

8.5

Open Issues

None

Proposed Voting Choices

Yes or no vote. 2/3 required to pass.

Patches and Tests

PR is available here: https://github.com/php/php-src/pull/17118

Implementation

Added in 8.5.

Final commit: https://github.com/php/php-src/commit/1c09c0c8323342aaaecbe444b3afa45efbd72ced

References

Prior discussion in July 2024: https://externals.io/message/124149

Rejected Features

Transferring Docker to another disk in Windows

Maksim Epikhin — Tue, 07 Nov 2023 11:42:24 +0000

Hello everyone Recently, I ran into the problem of insufficient memory on the main disk for a large project that is being deployed in Docker. The issue of transferring Docker resources to a 1TB HDD is fundamentally important, since there were no other options to deploy the project. And that's what came out of it...

To begin with, I will say that I have a WD Green 120G SSD, where Windows and some important software are installed, and other programs, projects and "personal life" are on the 1TB HDD.

They sent instructions on how to deploy the project, where there was a fairly large MySQL dump of more than 50 GB in size and a lot of containers. Somehow I didn't pay attention to this question, but in the process of a sooooo long installation, Docker collapsed and said:

I won't work, I turn off altogether, I'm stuffy and there's not enough disk space for me to raise your projects here.
I'm tired, I'm leaving!

The news was not pleasant. I turned this Docker this way and that according to all the instructions on the Internet and off the documentation, but it was under Windows that nothing came out. And yes, if you're in daemon.if you change the json data-root, then it simply will not work... It's great, isn't it?!

After a lot of time of tests and reconfigurations, I was able to find a solution! You may already know about him, so don't judge him harshly. I'm just trying to help "travelers in the Windows world with castrated hard drives."

And so, stop talking and let's get started. Do everything exactly according to the instructions and you will be happy. I must say right away that I have Windows with Docker on disk C, and I want to move it to disk D, where there is a Programs folder.

# shutdown wsl
wsl --shutdown
# export data docker-desktop
wsl --export docker-desktop D:\docker-desktop.tar
# remove data's regestration docker-desktop
wsl --unregister docker-desktop
# import data docker-desktop into new directory
wsl --import docker-desktop D:\wslStore\ D:\docker-desktop.tar --version 2
# remove D:\docker-desktop.tar

After these manipulations, all your DockerDesktop stories will be located in D:\wslStore . But, this does not mean that the data (containers, snapshots, etc.) will also be there. To transfer Docker data, an additional bundle of commands is needed:

# shutdown wsl
wsl --shutdown
# export data docker-desktop-data
wsl --export docker-desktop-data D:\docker-desktop-data.tar
# remove data's regestration docker-desktop-data
wsl --unregister docker-desktop-data
# import data docker-desktop-data into new directory
wsl --import docker-desktop-data D:\Programs\Docker\ D:\docker-desktop-data.tar --version 2
# remove D:\docker-desktop-data.tar

And only now it is under Windows that your Dokker will store all its junk along the way D:\Programs\Docker\

Similarly, you can transfer Ubuntu and other stories from wsl/Docker to where you need:

wsl --export Ubuntu ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu D:\wslStore\Ubuntu\ ubuntu.tar --version 2

I spent a whole day on these solutions: I tried one thing, then another - and here I found a working scheme for changing the Docker data storage directory under Windows.

I hope this information was helpful. Well, if not, then don't hit too hard :)

Setting up different PHP versions in Ubuntu on Apache2

Maksim Epikhin — Fri, 18 Feb 2022 14:05:28 +0000

This is a machine translation of the article "Configuring different versions of PHP in Ubuntu on Apache2" from my personal blog.

In this article, I will tell you my experience of setting up PHP of different versions on the same machine running Ubuntu Linux in conjunction with Apache2, xdebug and PHPStorm. It's not new, but I've had problems that PHPStorm didn't catch Debug on different versions, but preferred one.

Installing prerequisites

First you need to completely remove the existing PHP, and then install the required versions (we will install PHP 7.0 and 7.4) from the ppa:ondrej/php repository:

sudo apt purge 'php*'
sudo apt-get install software-properties-common -y
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update -y

# for version 7.0

sudo apt-get install php7.0 php7.0-fpm  libapache2-mod-php7.0 php7.0-mbstring php7.0-pgsql php7.0-xdebug libapache2-mod-fcgid -y

# for version 7.4

sudo apt-get install php7.4 php7.4-fpm  libapache2-mod-php7.4 php7.4-mbstring php7.4-pgsql php7.4-xdebug libapache2-mod-fcgid -y

Here we have installed the following packages:

php7.X is a metapackage used to run PHP applications.
php7.X-fpm provides a Fast Process Manager interpreter that runs as a daemon and accepts Fast/CGI requests.
libapahce2-mod-php7.X provides a PHP module for the Apache web server.
libapache2-mod-fcgid contains mod_fcgid, which runs multiple instances of the CGI program to handle concurrent requests.
php7.X-mbstring module for working with multibyte strings
php7.X-pgsql links PHP to PostgreSQL database
php7.X-xdebug module for debugging

Setting up xdebug debugging

Now we need to configure xdebug itself in the system and PHPStorm. To do this, go along the path /etc/php/7.X/fpm/ and add the section to php.ini:

# for version xdebug < 3

[xdebug] 
zend_extension=xdebug.so
xdebug.default_enable=1
xdebug.client_port=9000
xdebug.remote_autostart=1
xdebug.remote_enable=1 
xdebug.remote_host=127.0.0.1 
xdebug.remote_handler="dbgp"
xdebug.remote_port=9000

# for version xdebug >= 3

[xdebug] 
zend_extension=xdebug.so
xdebug.mode=debug
xdebug.client_host=127.0.0.1
xdebug.client_port=9003
xdebug.start_with_request=yes

In PHPStorm itself, the settings are made in Settings -> PHP:

Select the desired version and CLI interpreter
In the Debug section, uncheck Ignore external connections through unregistered server configurations and Break at first line in PHP scripts
Set Debug port to 9000 for xdebug version < 3 and 9003 for xdebug version >= 3.

You may need to add your local site address to the Servers tab, but this may not be necessary. Just in case, I will specify the setting:

In Name we write any name
In Host we write the address without a protocol to your site, for example, mysite.local

Setting up virtual hosts in Apache2

You need to create a virtual host configuration file:

<VirtualHost *:80>     
  ServerName domain.local
  ServerAlias www.domain.local
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/directory

  <Directory /var/www/directory>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  </Directory>

  <FilesMatch \.php$>
    # For Apache version 2.4.10 and above, use SetHandler to run PHP as a fastCGI process server
    SetHandler "proxy:unix:/run/php/php7.X-fpm.sock|fcgi://localhost"
  </FilesMatch>

  ErrorLog ${APACHE_LOG_DIR}/domain-error.log
  CustomLog ${APACHE_LOG_DIR}/domain-access.log combined
</VirtualHost>

Pay attention to the line SetHandler "proxy:unix:/run/php/php7.X-fpm.sock|fcgi://localhost". You need to replace X with the PHP version. In our case, 0 or 4.

How to create and activate sites, I think you know. If not, there are plenty of guides on the internet on this subject.

Reloading services

At the final stage, you need to overload the services and enable the necessary modules:

sudo systemctl start php7.0-fpm
sudo systemctl start php7.4-fpm
sudo a2enmod actions fcgid alias proxy_fcgi

That's it, now you have 2 versions of PHP on different local sites and xdebug will work on both sites.

Git Organized: My better Git Flow

Maksim Epikhin — Tue, 15 Feb 2022 11:58:32 +0000

In this article, I review the Git branching approach that I use in all of my development projects. Carefully, this approach is not as effective in maintaining existing software solutions.

How the branching organization is built

The first thing that should be - the main branch responsible for the final product (main / master / stable and others). We upload only ready-made and tested code to this branch, which then goes into release. Using the branch for other purposes is strictly prohibited.

The second point is the development branch. In this branch, we have a cut of the tested functionality code that is being prepared for release. This branch is not recommended to upload changes that are questionable or have not passed the tests. But, this moment is on the conscience of developers and testers. This development branch must be named as follows: development_MONTH_YEAR - for example, development_february_2022. You can go the easy way and call the dates numbers, but I prefer the verbal form for the months. Why create a branch every month? You will be able to see the development of the product every month and draw your own conclusions. This is convenient because you can tie product releases to the end of the month.

git checkout -b development_february_2022 main
or
git checkout -b development_february_2022 development_january_2022

The third point is task branches. Some people make new feature branches, but I prefer to create branches for each individual task. Most likely, you are leading a board and an issue in your project. Each issue has its own through number. This is how the branches are named: task_1 and so on. Each such branch must necessarily create from the current development branch (current month and year) in order to have actual changes. If changes have been merged into the development branch, then you must pull them into the task branch for updating.

git checkout -b task_1 development_february_2022

The merging goes like this:

Merge the task branch into the development branch
Development branch to master

Everything is simple and clear. And now it is worth mentioning the points on maintaining the board, as this is one of the most important functionalities in project management.

How to lead a board

Your whiteboard should have the following columns:

List
To do
Fix
In progress
Code review
Tests
Awaiting merge
Done

Here is such a simple organization of the board. Now I’ll tell you about the life cycle of a task by columns. The tasks that are in the List column are simply a list of all the tasks that have not yet been allocated. In To do - a list of tasks that need to be done in a sprint and already have a distribution for developers. Fix - tasks with errors. In progress - tasks that are being executed at the current time. Code review - tasks that are being checked by the team lead or other people responsible for the final quality of the code. Tests - tasks for testing by testers. Awaiting merge - tasks that are waiting to be merged into the development branch. Done - merged and closed tasks.

Now a little about the life cycle. First, no more than 3 tasks per developer are selected from the List and placed in To do. When a developer is present to solve no more than 1 task, he moves the task to In progress. After completing the task, you need to transfer it to Code review, from where it goes either to Fix or Tests. If the task got into Fix, then the developer, when he started solving errors, transfers it to In progress, and the cycle repeats. When the task is included in Tests, the cycle is repeated as in Code review. If the tests were successful, then the task is moved to Awaiting merge, and when merged into the development branch, it is moved to Done and closed.

Agree that this is a fairly simple organization of the task. What do you think?

UPD 18/02/2022

Made an omission on the branch. Look, we are creating a development branch from the main branch, and we are already creating a monthly development branch from the development branch. We fill the monthly development branch into the development branch and then from the development branch we create a new monthly development branch

How do you customize IDE for yourself?

Maksim Epikhin — Tue, 04 May 2021 12:59:07 +0000

Have you changed the settings of your IDE? If changed, what exactly?

Personally, I've changed a lot, including window layout, syntax highlighting, error inspection, and other things. Especially for a long time I set up CodeStye for most languages according to the rules for writing code.

I forgot to say that I use PHPStorm for web development.

What about PHP components? Ok, let's create. Part 1. Working with headers.

Maksim Epikhin — Tue, 04 May 2021 10:30:51 +0000

I do a lot of programming in PHP and every time something starts that doesn't reach the end, and so on. As a result of thinking, I realized that every time I decide to write my own system, framework or something else, I run into a problem. The problem is that I do everything around for the system to work, and not the system itself, or I write too dependent code. As a result, I decided that it was worth taking the time to write only components that will not depend on something personalized, but can depend on each other. This approach is also a bit weird, but still passing an interface to work is better than initializing another class inside a class. For example, for some component it will be necessary to use a database, but we do not know exactly what methods are there, so we operate with our own interface, where we ask to implement a class with such and such a method. Something we have gone from the topic to abstraction.
And so, I began to make my written projects in pieces. As a result, nothing efficient came out, as there were strong dependencies. I had to write again ... The first component that I decided to implement was working with headers. Why exactly he? Because most of the work is built around the communication between the server and the client. And here, just, you need to work with headers.
For all my components, I decided to adhere to the same logic of organizing the file structure: a folder for interfaces, a folder for exceptions, and the class file itself. The folder with interfaces must contain at least 1 interface for the class. There may be no exceptions in the folder with exceptions, because you don't always need to have personal exceptions.

src/
--- interfaces/
--- --- ClassInterface.php
--- exceptions/
--- --- ClassException.php
--- Class.php

Now let's briefly talk about the methods that are available in the class for working with headers.

set(array $params)
add(array $params)
remove(string $key)
removeAll()
has(string $key)
get(string $key)
getAll()

I don’t think it’s necessary to give a clear explanation of the methods, but if you are interested, you can look at the GitHub repository. True, now I'm translating my work into English, so don't be too surprised.

And at the end of the part, I want to note that there will be even more classes in the future. I try not to clutter up the post with code, since you can all look at GitHub. You can also download the project from composer packagist.

Create your own composer project

Maksim Epikhin — Thu, 17 Dec 2020 08:26:19 +0000

Hey. It has always been interesting to create your own project in composer, as it is a more modular and adequate approach when developing large applications. What is it for? The answer is simple: this is necessary in order to cut your tools into modules that can be used separately. For example, you can create a module to work with sessions, files, and more. Suppose you are making your own framework, which has a lot of self-written modules. And I, as a third party developer, want to use only 1 or 2. I don't need the whole framework! What to do? By resorting to packages (modules), you can provide this flexibility in the toolbox.

To implement simple packages, the composer config file looks like this.

{
    "name": "kernel",
    "description": "",
    "license": "",
    "keywords": [
        "",
    ],
    "authors": [
        {
            "name": "",
            "email": ""
        }
    ],
    "require": {
        "php": "^7.4|^8.0"
    },
    "autoload": {
        "psr-4": {
            "kernel\\": "kernel"
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

But if you want to make a project like Laravel, Yii 2 and other frameworks, then you need to have both the project core and its skeleton. In the case of the kernel, everything is quite transparent - the root folder of all the internals of the framework, where we will not climb. And the skeleton is the wrapper, the structure of the entire project. For example, a skeleton can contain empty folders required by the kernel, root files, and so on.

If you want to work with the kernel and skeleton, then the config file will look like this:
Kenrel

{
    "name": "kernel",
    "description": "",
    "license": "",
    "keywords": [
        "",
    ],
    "authors": [
        {
            "name": "",
            "email": ""
        }
    ],
    "require": {
        "php": "^7.4|^8.0"
    },
    "autoload": {
        "psr-4": {
            "kernel\\": "kernel"
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

Skeleton

{
    "name": "username/kernel-skeleton",
    "type": "project",
    "description": "",
    "license": "",
    "keywords": [
        "",
    ],
    "authors": [
        {
            "name": "",
            "email": ""
        }
    ],
    "require": {
        "php": "^7.4|^8.0",
        "username/kernel": "^1.0"
    },
    "autoload": {
        "psr-4": {
            "kernel\\": "kernel"
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

As you can see, there is some information hidden here, but the whole point is that the kernel is of type type by default and is a library. And the project skeleton has a type project. The kernel and its version were specified in the dependencies.

The launch of the whole miracle was like this: composer create-project HERE_SKELETON PROJECT_NAME. create-project will both pull and install all dependencies at once.

Thus, it turns out that to implement the libraries, you need to have only one project on Github, and if you want to use the project format, then you need to create a separate repository for the project skeleton and its core.

PSR + Experience = PHP code convention

Maksim Epikhin — Tue, 15 Dec 2020 22:14:04 +0000

The following points were formed by analyzing the existing approaches of companies and personal experience.

File and folder naming rules

All names for folders and files should be meaningful and self-explanatory (not requiring additional clarification).

Folders

All folders are named in lowercase, word-delimited using the - (minus) character.

If the folder contains classes that belong to the namespace, then the folder is named according to the name of the namespace.

Allowed characters for naming folders: Latin letters and the - (minus) symbol.

Files

All files related to the project are named in lowercase word-delimited using the - (minus) character.

If the file is a class file, it is named according to the class name.

Rules for naming namespaces, classes, methods and variables

All names should be meaningful and self-explanatory (not requiring additional clarification).

Namespaces

Namespace names must be in lowercase and consist of one word. If it is necessary to name namespaces for more than one word, it is split into constituent parts, which are nested namespaces.

Classes

Class names must match PascalCase. In PascalCase, each word starts with a capital letter.

Traits are postfixed with Trait. Interfaces are postfixed with Interface. Abstract classes are prefixed with Abstract.

Methods

Method names must match camelCase. camelCase must start with a lowercase letter, and the first letter of each subsequent word must be capitalized. All words are written together

The following rules apply to method names:

The name of the method should convey the intentions of the programmer
The name of the method should tell why this method exists, that it does and how it is used (isPostRequest, getRequestType, parseSchemaElement, renderPageWithSetupsAndTeardowns)
The name of the method should not be short
The name of the method must begin with a verb
Names of boolean methods must contain the verb is, has or can

Variables

Variable names must match camelCase. camelCase must start with a lowercase letter, and the first letter of each subsequent word must be capitalized. All words are written together

Constants must match UPPER_CASE_SNAKE_CASE. In UPPER_CASE_SNAKE_CASE, all words are written in capital letters, and spaces are replaced with underscores.

The following rules apply to variable names:

The name of the variable should convey the intentions of the programmer
The name of the variable should tell you why this variable exists, what it does and how it is used
The name of the variable should not be short
The name of the variable must not use the data type. The exception is Map ($typesMap, $statesMap), because otherwise, it cannot be distinguished from an array with data.
If a variable stores a trait, then it must be included in the name (unpaidProject)
Variables reflecting the properties of the object must include the name of the object (userIsAdmin, messageIsSend, figureCanBePainted, projectName)
Variables and properties of an object must be nouns and named so that they are read correctly when used, and not when initialized

Poorly:

$object->expire_at
$object->setExpireAt($date);
$object->getExpireAt();

Good:

$ object->expiration_date;
$ object->setExpirationDate($date);
$ object->getExpirationDate();

Names of boolean variables must contain the verb is, has or can
Negative logical names are prohibited

Poorly:

if ($project->isInvalid()) {
    // ...
}
if ($ project->isNotValid()) {
    // ...
}
if ($accessManager->isAccessDenied()) {
    // ...
}

Good:

if (!$project->isValid()) {
    // ...
}
if (!$accessManager->isAccessAllowed()) {
    // ...
}
if ($accessManager->canAccess()) {
    // ...
}

If there are properties (clause 8 and similar), the order of the variable name consists of: the name of the object in relation to which the variable is used), the property and the continuation of the variable name (userHasRoleAdmin, statusIsActive)

Code design rules

First of all, the namespace is put, which is used (if any). Next, the constructs of using classes (use) are written. In case of using several
Classes of the same namespace are grouped using the {...} construction. Next comes the class declaration.

Curly braces appear on the same line and are separated by a space.

Round brackets:

Inside are not separated by a space.
Outside separated by spaces control structures
There is no space after the method / function name.

Each variable must be declared on a new line.

Conditions and service calls of methods are separated by line breaks, variables and work with them by line breaks are not separated.

There is no additional line break inside conditions and loops.

The content of the class is delimited at the top by one blank line.

    class InterfaceType {

        private $property = 'myProp';

        public function getProperty(): string {
            return $ this-> property;
        }
    }

The return value (return) must be preceded by a line break if the method does not consist of a single line.

If the condition is large, then be sure to select it in one or more semantic expressions and use it (them) in the condition.

Poorly:

 if (IS_REGISTRATOR () && (($params.status === 'W' || $params.status === 'D' || $params.status === 'A') && $params.remark && ( ($params.subres_level == 0 && ($user_info->selected_title->tid == $params.boss || $user_info->selected_title->tid == $doc_signer_tid ||!$params.usertid) || $params.subres_level > 0 && $user_info->selected_title->tid == $params.usertid))) {...}

Good:

$docIsInWorkAcceptOrDraft = ...;
$bossHasSignerPriviledge = ...;
$userCanSign = ...;

if ($docIsInWorkAcceptOrDraft && $bossHasSignerPriviledge && $userCanSign) {
  // ...
}

Code commenting

In general, comments are prohibited (NOT "always"). Any piece of code that needs to be highlighted or commented out should be placed in a separate method.

Comments should be placed before the declaration of classes, variables and methods and should be formatted in accordance with PHPDoc. The comment before the class should describe the business logic and reflect its purpose with examples of use.

Single-line comments are denoted by //, and multi-line /*...*/.

Finished algorithms taken from an external source must be marked with a link to the source.

Rules for writing code

Where it makes sense, declare (strict_types = 1);

Functions / methods use null instead of missing scalar value. 0 and an empty string cannot be used as an indicator of a missing value.

function sendEmail(string $title, string $message = null, string $date = null): void {
    // ...
}

// message was not sent
$object->sendEmail('Title', null, '2017-01-01');

// an empty message was sent
$object->sendEmail('Title', '', '2017-01-01');

You cannot change the variables that are passed to the method as input (exception - if this variable is an object).

You cannot assign the same value to several variables. To check if a key exists in an associative array, use array_key_exists, not isset. You cannot mix string and numeric keys in an array. Associative arrays cannot be sorted.

Lines are surrounded by single quotes. Double quotes are only used if:

There must be single quotes inside the string
Variable substitution is used inside the string
Specials are used inside the line. characters \n, \r, \t, etc.

Instead of unnecessary concatenation, we use variable substitution in double quotes

Methods should use as much typing as possible, including the return type (: type). All parameters and their types must be described in the method declaration or in PHPDoc. Name methods that start with check and validate should throw exceptions and not return values.

All class methods should be private by default. If the method is used by the heirs of the class, then it is declared protected. If used by third party classes then public.

If the method can return null, then it is desirable to implement the Null object design pattern, or throw an exception, or return a special case object (example: an empty array).

When returning from a data method of the json type - it is unacceptable to writereturn true, always use the construction return ['success' => ['message' => '.....']] or ['error' => ['message' => '.....']] . message is given as an example, you can use any keys in an unlimited number.

The method must clearly distinguish between normal and exceptional situations.

By default, exception texts should not be shown to the user. They are meant for logging and debugging. The exception text can be shown to the user if it is explicitly intended to do so.

In a conditional statement, only the boolean value must be checked. When comparing non-boolean variables, strict comparison with type casting (===) is used, automatic casting and loose comparison are not used.

Poorly:

if ($user) {
     // ...
}
if ($request->postData('amount') == 100) {
     // ...
}
if (!$request->postData('amount')) {
     // ...
}

Good:

if ($user === null) {// $user is of type object
     // ...
}
if ((int)$request->postData('amount') === 100) {
     // ...
}
if ($booking->comment === '') {
     // ...
}

When using the AND and OR operators in a conditional expression at the same time, be sure to prioritize parentheses.

Opinion on PSR-1: Basic Coding Standard

Maksim Epikhin — Tue, 15 Dec 2020 18:31:04 +0000

After reading PSR-1, some thoughts came up that I would like to share with the programming community in order to get stories about your experience.

PSR-1: Basic Coding Standard — A standard that recommends rules for formatting and coding. Styling is how to write code, and writing is what to write.

The subtext PSR-1 says that you should not use mixing of code and logical conclusions of the code. I put it a little not clearly, but then you will understand that PSR-1 does not recommend writing a class, displaying it on the screen and initializing properties in one file.

All PHP files must use either <?php or <?=. Everything is obvious and understandable here, the first tag says about the declaration of a php code section, and the second is a short echo record, that is, output.

The files should also be in UTF-8 encoding without BOM, which makes sense. There was once a case in a project where there were several programmers. So, there one somehow managed to insert a BOM symbol and because of this, parsing files broke.

It also says that it is not recommended to use multiple side effects.

Well, here the moment is extremely controversial. Although the standard recommends using an autoloader according to its PSR-0 and PSR-4 standards. On the one hand, yes, but there may be application initialization at a single entry point. In short, the moment is doubtful. In the same Yii2 this approach is not followed … I would not pay attention to this very recommendation.

Let’s go to the section of class names and namespaces (namespace). Here I agree that the class file should contain only this class, that the class should be in the namespace. Class naming should be in StudlyCaps format. We will not consider options for writing code for PHP versions <7.0, as there are some nuances, and the demand for versions below is quite small.

We name constants in uppercase, separating words with underscores DATE_APPROVED. Everything is logical and understandable here, there is no point in naming them like properties or variables. It is necessary to clearly distinguish constants from properties.
But with the naming of properties, I do not agree with the recommendations. PSR-1 recommends using one of the following formats: $StudlyCaps, $camelCase, or $under_score. I don’t really like the messy code and rely on the opinion of each programmer. Personally, I, probably like many programmers, believe that there is only one style to use, and it should be $camelCase. Moreover, the standard is tricky, it says that these rules can come from code suppliers of different levels … Now, if the naming standard was adopted specifically, there would be no disagreements. Although I have not seen writing code in a different format from camelCase for a long time.

With camelCase() method naming, I completely agree and support. It is logical that we name classes with a capital letter, constants with a small letter, methods with a small letter. And, in principle, you can distinguish one from the other simply by writing.

Thank you for your attention, I hope that the material was useful, although it is a statement of thoughts on reading PSR-1.