Modern PHP Cheat Sheet(front-line-php.com) |
Modern PHP Cheat Sheet(front-line-php.com) |
PHP has come a really long way, I really hope to see it's resurgence some day after everyone has been burned enough from running JavaScript as their server.
People seem to love to hate it because it's the "cool" thing to do. Yet PHP developers continue to ship things faster, while JS devs are probably still fiddling with their Node environment setup...
While I agree with this, I think the tone is slightly dismissive. From what I have seen, older people in our trade seem to recommend against PHP due to it having a terrible relationship with consistency, functionality, performance, etc. in its history. Though I have (thankfully) seen that the language and its standard library has undergone several large improvements, which is great to hear.
> Yet PHP developers continue to ship things faster, while JS devs are probably still fiddling with their Node environment setup...
On your point of JavaScript, the build environment nonsense can definitely get hairy. It's why we get things like Deno, which attempt to throw all this cruft away and start again. And sometimes that's a good idea. If you're dedicated to Node, replacing Webpack with Rollup seems to be what is generally recommended. The only obvious disadvantage there is compatibility with Webpack plugins.
It would be nice to have a type-checked JavaScript variant with a practically non-existent build environment (no Webpack, Rollup, etc.) As much as I adore TypeScript, the compiler itself is massive and takes quite a long time to even start.
Really happy to be working with it again, even if on the side for now.
For example, PHP could get along without async/await and promises in a lot of situations, because threading was effectively subcontracted to the underlying web-server. You could just treat, say, a curl call as blocking-- resulting in a simpler code flow-- knowing that wouldn't lock your entire web server.
The improvements over the lifespan of PHP7, and the new things in PHP8 make PHP such a nicer language to work with.
Just needs a FastCGI wrapper.
Another "Node, but PHP like" project that compares itself to EJS and other similar things: https://github.com/Yahweasel/nodejs-server-pages#why-nodejs-...
> Use the _ operator to format numeric values:
> $price = 100_10;
> // $100 and 10 cents
Makes it sound like the underscore replaces the decimal, which it doesn't. The underscores are simply ignored by the PHP parser, so that 10_0.1 === 1_00.1.
You could afterwards use PHP to replace the `_` with a comma for display purposes, and I assume that is what they are trying to say.
They really should just use a simpler example, like 10_000_000 being easier to read as "10 million" than 10000000.
> They really should just use a simpler example, like 10_000_000 being easier to read as "10 million" than 10000000.
Numbers can contain underscores for readability purposes.
These do not affect the value of the number, but can help read large numbers
more easily.
141592654 # how large is this number?
141_592_654 # ah, it's in the hundreds of millions!
Like all `Readability` issues, this one is not a technical concern.
But you can improve the odds of others reading and liking your code by making
it easier to follow.
[1] https://github.com/rrrene/credo/blob/master/lib/credo/check/...
And I've been loving all the new additions to PHP over the last few years as well. Version 5 was rather limited but since 7 it has grown into an actual programming language for which I feel I don't have to apologize for.
I guess it might be Stockholm syndrome - but I'm quite comfortable with a "list/array" type (numeric keys, ordered) and a "map/hash_map" type (objects as keys).
Especially give that with phps "power" you can:
$array = array(
1 => "a",
"1" => "b",
1.5 => "c",
true => "d",
);
var_dump($array);
array(1) {
[1]=>
string(1) "d"
}
And for the record, it's not Stockholm syndrome, I use plenty of other languages and I know the benefits and drawbacks of each of those.
It's not 'a' ⇒ 1, it's 'a' => 1, just write it out the correct way. Why are you trying to be fancy?
EDIT: I wrongly assumed at a glance because of the shape of the $. On closer look the characters are much wider than iosevka. It's jetbrains mono
PHP stdlib needs an overhaul, IMO.
However you do have options to choose from with php these days. Really well maintained libraries exist for basically everything you could want, often they are fast, well tested and modular. And it's nice because you can even choose the style you prefer with this.
Grab the symphony string lib for instance: https://symfony.com/doc/current/components/string.html
https://mobile.twitter.com/woketopus/status/1447150924846313...
[1] https://spatie.be [2] https://freek.dev
PHP should have chosen to undergo a rebranding a few years ago, if you ask me. The stigma it has to deal with is probably unsurmountable and will be forever. If you think PHP, you think WordPress and Joomla, and that means "hacks and vulnerabilities"...
It's a good language nowadays, with quirks like any other language, but I still have one big problem with it: There are too many "PHP developers" out there, and most of them are very bad, and many of the good ones are from poor regions in the world and you can find them on Fiverr doing kick-ass work for a grand total of $50.
if (md5('240610708') == md5('QNKCDZO')) {
echo "true\n";
}
php > echo md5('240610708');
0e462097431906509019562988736854
php > echo md5('QNKCDZO');
0e830400451993494058024219903391The 5840 built-in functions provide easy ways to get many useful things done with minimal dabbling.
In other words, one can be a "scripter" instead of a "programmer", and for many projects that's 100% OK.
Other languages automatically filter out "scripters" from their field by demanding a certain level of mental abstraction to produce anything moderately useful.
While there is absolutely no difference between a good programmer using PHP, or a good programmer using any other language/environment, but there is a big difference between the median levels and below.
This in turn lowers the reputation of the field, and it becomes uncool to put PHP on one's resume, therefore the more capable programmers propagate out to other languages, which further lowers the median, etc.
This happened with Perl, too...
It would really make writing scripts a lot easier and cleaner.
This approach also has the added bonus of stopping PHP from accidentally evaluating something inside the strings.
It’s really weird to me, I mean don’t we do this all the time? Work with eg. an $options array/obj passedto a constructor, or say, a message decoded from JSON…
I could write $name = $message[‘username’] … and there is no checks in ide or runtime, while the phpdoc will just document $message to be an object or array… what am I missing?
It looks like php devs create full blown classes to represent just about every data strcuture, but what if it’s just data and you don’t need any attached logic’ Isn’t there a concise way to declare a complex type?
It really needs a way to declare type of small data structures though, in a very concise way (no class boilerplate, for performance eg. going through 10000’s of entities).
PS : on the other hand I’m starting to dislike how languages become "designed by committee", and lose the purity of the original design.( thinking of JS mostly here with its gazillion rfcs)
JavaScripts nullish coalescing operator landed in chrome 80 (feb 2020) over 5 years later… more like it’s PHP syntax landing in JS land.
> Union Types - Combine several types into one union, which means that whatever input must match one of the given types: `function find(int|string $id)`
TypeScript and PHP have the distinct honor of being a popular language with ad-hoc union types (not the concrete subclass/enums that other languages seem to think are sufficient).
I wish frontend developers would stop messing with UI :(
Some of us edit the styles as normal practice for a large number of sites, especially after the widespresad use of thin fonts, grey text etc.
Surely there will also be tools (add-ons) to replace css elements as needed per domain...
The opposite is PHP5-style code from the early 2000s, no package management, no type strictness, no object orientation, just a giant spaghetti mix of JS, HTML, SQL and PHP in a 10kloc file.
Typed properties, constructor properties, and Read-only properties can significantly reduce the code bloat.
- https://php.watch/versions/8.0/constructor-property-promotio...
If I have a function that receives eg a Message, it means an instance of the class right? So somehow my assoc.array/object still needs to be instanced, and if I do just $message = new Message($theData) … it doesn’t auto assign properties right? That would be handy though still very much boilerplate.
I guessthe language is just designed for how it’s been used so far, may e it will change if JIT makes php more open ended in its uses.
Here's two of the most common ones. These are very mature and are very broadly used. Most editors also come with some support for these annotations so you often get help in the editor when something is wrong.
https://psalm.dev/docs/annotating_code/supported_annotations...
The examples you mentioned are interesting because I consider `options` arguments to be a code smell that tends to happen because TypeScript is missing named parameters, which PHP has. And typing JSON messages is far from a solved problem in TypeScript, because there is no widespread solution for runtime type checking.
The 7.4 did not finish the type system work. Docstrings were still needed for basic type hunting.
Exceptions as expressions--I can stop writing, `$x = $context['x'] ?? ThrowWrapper::missingValue('x');`
Named Arguments -- I use a hacky diy `Reflection` heavy version of this for an RMI/dispatch where json key-vals mapped to function params.
Static return type and union types -- I have been relying on PhpStorm docstring hacks for this sort of type-hinting.
`readonly` will be very helpful to express performant, immutable classes. I have a number of classes that are immutable-by-convention, trusting the caller not to monkey with the internals. (The idiomatic way to do this, `$immutable->getAttr()` is too costly in tight loops compared to `$immutable->attr`)
PHP still has lots of warts (function calls why you so aspensive?!?!?) but I keep being pleasantly surprised by how good of a tool it's evolving into.
Static return type, useful but since I use interfaces for everything it's not really needed. Union types, also not really needed because either 2 interfaces share a common ancestor or I'll have separate methods for different types. But most of the time, I encapsulate things behind interfaces that do one thing, so having different methods per type can often be avoided.
Named arguments are a pain for me since now I can't change parameter names anymore. This is particularly annoying with different coding styles in dependencies vs my own code. My code ends up not conforming to the coding standard that I've used since it was introduced (PSR-2R).
Exceptions as expressions is a nice to have, but exceptions in general are a thing to avoid doing. Not that things can't go wrong, not that chugging along in the face of errors is good, of course it's not. But if you have a lot of exceptions in your code, that's a smell of bad design. I've got 13 different exceptions used 20 times in total, over 4683 LoC on my current project. Mostly, whenever one of them is triggered, whatever I changed last was incomplete and led to an inconsistent configuration.
That said, your use case for PHP is probably very different. Especially since I don't care much at all about performance anymore. I used to, but CPUs are so much faster nowadays and PHP itself has improved.
However I don't think it is something that will ever be done, designing a good standard library is quite difficult, especially by email and rfc.
I think it is better if the community designs one that gets a lot of traction to become de facto standard. All the large frameworks already has their own standard library.
With the performance improvements to PHP over the years it is no longer a detriment to performance to write a standard library in PHP.
And if we can get the operator overloads rfc passed we can have userland scalar objects
And the context here is how to explain it, not whether it should exist and/or be used.
That's what I'm replying to.
[1]: https://www.php.net/manual/en/language.types.string.php#lang...
[1] https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
php > echo strcmp(md5('240610708'), md5('QNKCDZO'));
-4As an older person in the trade, I don't agree with the other older persons. Only consistency is a problem with PHP code, and that is largely NOT caused by PHP. Inconsistency is the product of developers coding without any real thought about how to abstract things (ok, well, maybe not in the case of magic strings). You can do this with every language. Some languages do everything possible to force consistency, and developer still find a way to be delightfully inconsistent even with the syntactic equivilent of bowling gutter bumpers (see Cobol, Go, Java). Consistency is a developer problem. You can write great code in languages that are terrible.
PHP has never been slow (compared to other dynamic languages), or lacked functionality. If there is a rub on PHP it comes from no separation of code and presentation, which flew in the face of the MVC pattern which was THE WAY for a very long time. Now... well, JSX much? Anyhow, my team works with Go, JS, PHP and Python, and the code that takes the least effort to both extend and maintain is... the PHP.
It just. Doesn’t. Matter. Choose Symfony or Laravel, and you are in for a wonderful development experience, from setup to dependency management to architecture to implementation to testing to deployment – for certain kinds of projects it’s just perfect.
The truth is, those who care to use the language properly know this already. Those who wish to dismiss it always will, and this happens to be an easy angle of attack.
Doubt. Your "something@v1.2.3" in Deno is no different than "something": "^1.2.3" in npm. The problems will appear when you update stuff.
The only thing benefiting deno currently is the clean slate and the lack of hacks (for now).
However if the argument is: updating libraries break stuff, that is gonna happen every time in every language. There is no guarantee the next version will just work as the last one did
Anyway I was curious so I wanted to try this out with the trait method here is working code that illustrates this.
<?php
/* trait to cast from any iterable to class */
/* reusable - close to what I think you are asking for */
trait castFrom
{
static function castFrom($data)
{
if (!is_iterable($data) and !is_array($data) and !is_object($data)) return null;
$class = new self();
foreach((array)$data as $key => $value)
{
if (!property_exists($class, $key)) continue;
$class->$key = $value;
}
return $class;
}
}
class Foo
{
use castFrom; // use the castFrom trait
public string $str = 'blah';
public int $num = 5;
public function hello() { echo "{$this->str} : {$this->num}\n"; }
}
class Bar
{
use castFrom; // we can use the castFrom trait again and again
public int $x = 0;
public int $y = 0;
public function hello() { echo ($this->x * $this->y) . "\n"; }
}
$data = ['str' => 'foo', 'num' => 7, 'x' => 3, 'y' => 7];
$foo = Foo::castFrom($data);
$foo->hello();
print_r($foo);
$obj = (object)$data;
$bar = Bar::castFrom($obj);
$bar->hello();
print_r($bar);
/* you could just use create functions form the class */
class Creator
{
static public function createFromArray($data) {} // create from array
static public function createFromObject($data) {} // create from object
static public function createFromSerial($data) {} // etc..
static public function createFromJson($data) {}
}
class Foo {
public function __construct(string $name, array $options)
{
$this->name = $name;
if ($options->enableFlag) { ...
type TFooOptions = { enableFlag: boolean; userIds: number[]; }
Then
function __construct(string $name, TFooOptions $options) ...
is that creating a JS class under the hood or is just a hint for the compiler?
What I do , but I don't work with recent PHP versions is to create this as a class, then to make this easy to construct objects from JSON i add a static function fromObject or fromJson that does it for me. Using real classes could prevent bugs when working with shit APIs like Microsoft TTS , where they have 2 endponts and one returns objects like voice: {name:"Bob"} and the other voice: {Name:"Bob"} so my code will wrap both type of responses into a well defined class.
I don't think there is a PHPDoc annotation just to hint what that object looks like but I will be happey to be shown a way.
class TFooOptions
{
public function __construct(
public bool $enableFlag,
public array $userIds = [],
) {
}
}
$options = new TFooOptions(
enableflags: true,
userIds: [1,2,3]
);
new Foo('Bob', $options);
[1]: https://psalm.dev/ [2]: https://psalm.dev/docs/annotating_code/type_syntax/array_typ...
https://www.typescriptlang.org/docs/handbook/2/everyday-type...
Your approach is sensible. I remember using json_encode() indeed so I could declare some data in a php file with <<< HEREDOC in the Javascript short syntax (though short array syntax in php nowadays makes it less painful, JSON syntax still a bit less verbose).
Developer speed does not get enough coverage when comparing languages.
When I work with a Node project it's such a slow dragging build process.
Using PHP is like a fun superpower that lets me turn out things on timescales that are borderline miraculous to clients and management.
I can hire a top-notch PHP engineer for half of what a mid-level JS engineer would be asking.
It's not that PHP engineers are less qualified than JS. I think bootcamps shifted the market for JS developers and now really good engineers cost an arm and a leg while good junior engineers start around the $100k mark. The whole JS salary market is insane and as a startup, I can't afford it right now.
Just pay what good engineers should be paid. If there are PHP developers out there not getting the same salary as a their peers like this post mentions, you should leave that job for a better one. Please demand better, PHP developers, for all of our sakes. Business always wants to put downward pressure on salary and we need to be united against this regardless of preferred tech stacks
It’s exactly 180 degrees for me. Node js just seems to be super fast. And with typescript its heavenly.
I don't make a website and working on node js is fun. In PHP it is like doing something esoteric. Just a simple argument parsing is so hard in php compared to node js. In nodejs I use meow and even without docs, I can parse cli easily. In fact, I think Rust can be more easier than PHP in many cases. I usually rewrite in rust for long term daemons. Also in php I need to install php I don't know why I should install php-pdo etc. I mean why not just allow composer etc to handle like just like node do? I am frustrated with php stdlib which seems to be fossil at the moment.
The thing I like about PHP is laravel framework where I can set up websites instantly. Node js is fragmented with adonis and many other micro-framework.
With Drupal, the code quality of the core is generally okay, however the added inertia may come from a "square peg, round hole" situation, where the CMS is being used for an obscure purpose for which it wasn't really designed. This is quite common in the wild, probably due to the low barrier to entry and the fact that people will use what they are comfortable with to solve every problem under the sun (not dissimilar to the prevalence of Excel throughout the world of finance for a variety of completely inappropriate use cases).
I've run no numbers, I have nothing but infrences to base this on, but hiring a mature PHP engineer in Europe would 100% be cheaper in the long run than hiring a junior/mid-level JS engineer anywhere else.
https://symfony.com/doc/current/console/input.html
Installing laravel for cli is like buying thread ripper to run minesweeper.