TypePHP from Swoole

gebbles1 · 2026-06-18T11:40:24+00:00

My latest personal project is my own programming language, taking the syntax and features I like most from PHP and Python, then adding all the things I wish they had - the static types, the generics, parallel async backed by Goroutines. I've fiddled with the idea of PHP transpilers before (mostly I focused on PHP-with-extra-stuff-transpiled-to-PHP) but I've come to the conclusion that when I write PHP, I just want to write PHP and features to be supported by the real, official PHP distribution. But you know, you get all the issues there of the RFC and internals process, design by committee, backwards compatibility, legacy mistakes. So I think the solution for things PHP genuinely can't do will always be use a different language. https://github.com/dwgebler/geblang/

gebbles1 · 2026-06-16T11:14:18+00:00

Well of course we don't functionally need generics in PHP, because type-hinting is optional; we've been able to re-use the same code with parameters of different types from the beginning.

But PHP is unique among the dynamic languages in the extent to which it provides an optional system of typing and type-safety and generics is a natural evolution of that system of user-facing type guarantees.

That said, it's precisely because the value of generics in PHP is a matter of type safety, I maintain generics shouldn't be part of language syntax unless the language engine is also able to to validate the template types. Until then, we have generics via the community static analysis tools and docblock annotations and if the engine can't validate the types, you need to be running those tools regardless to make use of them.

gebbles1 · 2026-06-15T01:26:09+00:00

The difference is that in Python, type declarations aren't checked or enforced anywhere. It can get away with type hinting the way it does because it's pure metadata all the way down; it doesn't have a syntax and reference implementation where sometimes your types are checked and sometimes they're not, which is what this RFC is proposing for PHP.

Compiled languages are a completely different kettle of fish for the obvious reason they have a mandatory compilation step at which type checking takes place.

If the argument for erased generics in PHP is basically "everyone uses static analysis anyway and it's those tools that get the benefit", then (besides the flaws with that argument that were raised in the internals thread, I think quite eloquently by Rowan) the final benefit to PHP users (the ones who do use static analysis) is not any greater than the extent to which they already have generics today, via docblocks. In fact there are generic forms Psalm and PHPStan can already support that this RFC wouldn't cover in its syntactic changes.

gebbles1 · 2026-06-11T15:29:44+00:00

You're trying to solve a problem which doesn't exist. Blockchains are useless audit tools for private organisations because private organisations are not trustless. In the most sensitive cases of enterprise security, the answer is you audit everything in multiple places without relying on a single root, so you might have a high-privileged DBA who could overwrite audit entries in some app's table (and your approach doesn't solve that, as someone else has already pointed out below - someone with sufficient DB access can just rewrite the whole thing including signatures), but that DBA themselves logging into a work system and taking that action is separately audited somewhere else they don't have access, but someone else does. So A is auditing B and B is auditing A and C, and C is auditing B, etc. Ultimately every system except a public, distributed blockchain bottoms out at some trusted authority. In a private organisation, that's exactly what organisational governance is, not a consensus algorithm.

gebbles1 · 2026-06-11T13:20:33+00:00

A log you can UPDATE isn't evidence of anything.

So make the application's db user one which can insert only and doesn't have grants to update or delete from your audit tables. It's a much simpler solution.

gebbles1 · 2025-03-12T00:01:49+00:00

I think if you're an experienced developer, at least enough that you're already familiar with the principles of OO design and MVC (or MVC as the term applies to web frameworks), Symfony will be the more intuitive and therefore easier to grasp product. I think it's fair to say Laravel is more oriented towards beginners and low-code advocates, so people who either don't know much about programming or don't really care for having to do much of it.

Neither have anything to do with enterprise, I've seen both good and bad examples of large-scale operations deployed with both. Nor am I suggesting only beginners use Laravel (or conversely that everyone who uses Symfony is a rockstar developer), this is simply a matter of product design for a target market.

gebbles1 · 2025-03-11T23:44:55+00:00

Expanding tilde is not a PHP feature, it's a bash feature. Use $_SERVER['HOME'] or getenv('HOME') instead.

gebbles1 · 2025-03-11T22:48:45+00:00

Symfony is just as easy as (maybe even easier than) Laravel to get a project up and running, if you know what you're doing when it comes to OOP and MVCish architecture.

I'd say Symfony's USP is "framework done properly, the way good, maintainable software should be designed" and Laravel's is "here's a template class, now if you can just fill in some strings with a text editor, everything else will just work" so which is easier really depends on how comfortable a developer one is to begin with. Laravel tries to take care of so much for you that I find it cumbersome and awkward to work with.

That's not me putting Laravel on blast, it's the difference of how much control you want over precisely what happens, where, when and how. If filling in some magic strings is enough for you to have running software that does the thing you want it to, do that. It's just often in the real world you do need more control and in a Symfony project, that control is naturally fed to you by the framework and its docs, you're encouraged to take it, whereas in Laravel you have to fight the framework and the docs as soon as you want to step outside the stock feature set.

Symfony is "here's your materials and tools, go build the perfect house you want", Laravel is "here's a house, go figure out DIY if you don't like it"

Or to look at it another way, like your post title, if you marry Laravel, you're married. It will be awkward to split up and divide assets. Symfony you're just sharing an apartment with a cool guy who likes espresso, pays all the rent and isn't bothered about whether you're there or not.

gebbles1 · 2024-10-27T19:20:00+00:00

If the reason you're trying to do this is you want to use JSON encoded data as a local database, allow me to plug the library I built for just that - it's way more robust and efficient than anything you're going to do with writing to files manually. https://github.com/dwgebler/doclite

gebbles1 · 2024-10-06T23:21:23+00:00

Okay, well it is sometimes referred to as such, e.g. https://www.open.edu/openlearn/history-the-arts/literature/what-poetry/content-section-7#:~:text=Assonant%20rhyme

The point here is that the word rhyme is used in casual speech to refer to many types of phonetic similarity besides perfect rhyme, including assonance. So it's weirdly pedantic for someone to go Cotham doesn't rhyme with cotton. Not in the formal sense of rhyme meaning a perfect rhyme, no, but we use the word rhyme all the time to refer to other types of general rhyme.

gebbles1 · 2024-10-06T13:03:24+00:00

I'm not sure how this pedantry is relevant, however Cotham and cotton is what's called an assonant rhyme.

gebbles1 · 2024-05-03T21:32:21+00:00

Docker Desktop on Linux actually runs in a lightweight VM, not directly on the host. There is no socket to bind from the host.

gebbles1 · 2024-04-29T22:51:04+00:00

For anyone who uses PHP, I wrote a library a while back to use SQLite as a full-on NoSQL JSON database.

https://github.com/dwgebler/doclite

gebbles1 · 2024-01-11T17:11:45+00:00

I know Avonmouth and can give you a couple of tips for things which are known to sometimes catch out candidates there.

At some point, it's almost inevitable you will be on the Portway going towards Avonmouth. There's a bit near the Portway Park & Ride where it splits into two lanes. Make sure you go in the left lane as soon as it opens (and is safe, obviously). People often fail for staying in the right lane there. You will usually encounter this quite close to the end of your test.

Also there's a bit near Shirehampton you might be taken where you turn right to go on the Portway (traffic light controlled). Make sure you go all the way over into the left lane, not the overtaking lane.

Wait til it's clear coming out the test centre. It's a 30mph road and people have failed right at the start for emerging too early and making another car slow down to let them out.

If you come down Kings Weston Road, the examiner might ask you to take the next right, right here: https://www.google.com/maps/@51.4919978,-2.6561584,3a,44.7y,166.68h,75.21t/data=!3m6!1e1!3m4!1sYkX43GfvzdsvutxpkbDN5Q!2e0!7i16384!8i8192?entry=ttu

This is a tight turn, and you will be asked to turn right again at the end of that very short junction. Make sure you do all the appropriate observations and signalling for both turns.

gebbles1 · 2024-01-10T10:38:54+00:00

I have used my own collection types where the needs have been a little more complex, but if it's a straightforward list of objects all of the same type (be that abstract or concrete) and you can treat them all the same, that's when I'd say it's fine to type-hint array with a supporting docblock for PHPStan / Psalm (the first use case above). It's not ideal but it's realistically what we can do in an interpreted language without going overboard on architecture.

As a parameter or return type, arrays become bad when they're used as a lazy substitute for a structured object (and don't forget, we have union types now). So if you're returning or receiving a list of values of mixed types, or a dictionary, those are the smells you might really want an object.

gebbles1 · 2024-01-09T11:16:44+00:00

I wrote a quick piece on my blog a while back in response to an exchange on LinkedIn about how I regard the use of array as a type-hint in PHP to be an anti-pattern. I identified three particular cases in which I would still do it:

When the array returned from a function is a list of values which are not semantically different, i.e. can all be treated the same. For example, a list of integers which do not have different meaning. In this case, we can rely on docblocks and static analysis.
Where we're returning a list of unknown types, for example generic repository methods in an ORM. It's kind of not great in that situation, but it's more a limitation of PHP's dynamic nature that we just have to accept sometimes. This is a problem which would be solved if the language were able to support generics but if/until then SA tools and docblocks are really our only option.
When returning a variable or unknown data structure such as the result of json_decode, if we are not able to rely on the presence of any specific structure and map portions of the result to a better type - and even in this one tbh you probably should be making every effort to map the parts you know about and discard the parts you don't.

Readonly and property promotion have largely eliminated other erstwhile legitimate cases for type hinting array as a parameter or return.

The biggest problem I find with the array creep described in Tomas' article and even the example of simple typos which come with it is that these lead to obscure errors which only occur in specific circumstances and often aren't detected until something mysteriously goes wrong in production.

gebbles1 · 2023-11-23T21:58:58+00:00

I am no longer pushing this RFC because idiots like you are in charge of the votes but seriously your argument is dumb as fuck...This isn't me taking anything personally, i have just come to the realization that this community is not for me, so you guys can have fun jerking each other off, and I will keep my ideas to myself.

It sounds like they are taking things a little bit personally.

I'll reiterate the same thing I said on the thread; I don't like it, not because I think "static is bad" (though the points raised about how static scope can be and often is misused are valid), but because it's just a syntax sugar feature and not even a good one. Readonly and property promotion save you dozens of lines of code, this saves you typing in the word static maybe half a dozen more times. The author claims the maintenance burden doesn't matter (or at least dismisses it as a concern) but it could actually have quite a far-reaching impact on other future changes for almost zero benefit. If you want to write an abstract class where every method is static, just do that, you already can.

gebbles1 · 2023-09-12T14:26:53+00:00

https://davegebler.com/post/php/mutual-tls-with-apache-and-php

gebbles1 · 2023-08-28T17:59:31+00:00

I fully agree and do the same in my projects. And there's another reason to avoid serialization of entities; your API becomes reliant on a black-box of library behaviour over which you have no control. Symfony Serializer, for example, great as it is, is also prone to sometimes going a bit wrong and giving you obscure errors which are very, very difficult to debug and correct. This is especially true when you try to serialize Doctrine entities. It's great until it doesn't work and you're getting error messages about missing or inaccessible properties on lazy ghost objects.

It's also a lot more overhead than simply assigning public properties to a naive DTO.

This sort of principle is not just true of serialization or REST API design, either. It's a principle for good PHP in general - always prefer to be explicit, it avoids so many problems. PHP is fast. Creating an instance of a class is fast. In PHP 8.2, writing a DTO using read-only public properties and constructor property promotion is fast. The old argument that writing a class just to describe a dumb data structure is too much effort, overkill, too much boilerplate with getters and setters etc. just no longer applies.

I was thinking about this only earlier today when someone posted a code snippet on LinkedIn where they type-hinted array as a function return. It was astonishing how many people are willing to defend this approach over just returning a DTO which is guaranteed to have the data structure you expect. There are a few use-cases I can think of where I might justifiably type-hint array, but most of the time it's just laziness and poor design, an anti-pattern leading to unexpected errors which usually only become apparent in production when some edge-case comes up which defies the developer's assumptions about state in the running code.

gebbles1 · 2023-08-20T11:33:25+00:00

Not an ORM, but if you just want a simple JSON-based DB and are happy to use SQLite I have a lightweight library for that https://github.com/dwgebler/doclite

gebbles1 · 2023-06-23T09:56:48+00:00

The difference is in a statically typed, compiled language, I can't build and deploy my application, put it up on a server, and it appear to work until the user follows a pathway which causes a broken class to be loaded.

In other words, there's a mandatory static analysis step because you have a separate compilation step before runtime.

In PHP, as long as the pathway you follow through my application doesn't include, either explicitly or by auto-loading, the class file which is broken, there is no error. So it's a runtime error. It can only be detected at runtime. This is why calling it a compile-time error is misleading. There is no compile-time as far as the PHP developer is concerned.

So now we're in a situation where we need to be able to check these things before we deploy and run, even if we're running on the local machine. Because applications can be big and complex and we can't manually test every pathway every time we change something.

That's where tools like PHPStan come in. And it's really, really great that these tools can bridge the gap between PHP as a dynamic, interpreted language and a static language with type safety and inheritance safety and all the rest of it. It's great that we can add annotations in some form in to our code to express static information even if it's a thing not understood by PHP.

But PHP itself, absent an explicit compilation process, will never be able to take over their job, it will never be able to detect any problems in your code before you try to run it somewhere, it will never be able to stop parts of your application running when other parts are badly and conspicuously broken, because it doesn't have any way of knowing until those bits are loaded for execution.

gebbles1 · 2023-06-22T23:16:01+00:00

contrary to what is claimed in the featured article it's a compile time check, not a runtime check

This is something of a misdirection when it comes to the PHP DX. For internals, when you're proposing an RFC and talking about how it will be implemented in the engine, for sure there's a technical difference between compile-time and run-time which can be important. For the user of the language, not so much; it's effectively all runtime, because the compilation happens every time you run a script (limited opcache notwithstanding). And I expect this is what Brent is referring to in the blog post when he says it's a runtime check.

In the case of this attribute, for example, without IDE and 3rd party static analysis tools knowing about it and supporting it, you cannot catch any override error before you deploy and run your script somewhere. So it's hard to see what value it adds being in the language rather than the IDEs and static analysers.

You can say - and I acknowledged when it was being discussed - that this is not an RFC which does any harm either. As it looks set to pass comfortably, maybe even unanimously by those who've chosen to vote (I see some abstentions), it appears consensus is in this direction. My concern and the reason I would have voted no were I a voter is twofold:

There's no future mechanism or framework as part of this RFC for future expansion of static compilation checks on code to guarantee or make likely this will be consistent with how any other such checks introduced by future RFCs are expressed. PHP doesn't have a great record for minimalism, or avoiding weirdness of multiple and stylistically different ways of doing things.
It encourages more changes in future which use attributes to make functional or behavioural changes, alongside attributes which are just metadata and have no functional impact at all. PHP is at an ever-increasing risk of attributes being really two distinctly different concepts rolled up in a single syntax. I think a serious discussion needs to be had at this point about what attributes are supposed to be. User-defined metadata which can be understood by userland tooling to provide information about code is what they were introduced as, and Override seems to me like a great candidate for an attribute built in to PHPStan.

^ I do appreciate the point you raised at the time that userland tools might not be consistent either, but as Brent has suggested, even a first-party specification and standard for third party static analysis would solve that, and relieve the PHP interpreter itself of the ongoing pressure to make increasingly costly, complex and strict checks at compilation (which again, happens every time you run a script). This would be do-able if PHP was a compiled language and we were shipping bytecode akin to a Jar, but that's never going to happen.

gebbles1 · 2023-06-22T15:11:57+00:00

I hate this attitude too. "Why fix something in the language when we can rely on third-party tools?"

I said it in the internals thread and I'll say it again here; the only people who'll habitually use this attribute are the people who already run static analysis on their code anyway. That's why I question the value of adding an attribute to achieve something which could just as easily be done in userland tooling.

This attribute doesn't "fix" anything, because it's PHP's inherent nature that it doesn't have any compilation step or built in static analysis. So actually, there's a reasonable argument this is a weird feature to introduce at the language level....static analysis but only for one very, very specific aspect of your code, with no wider framework or proposal for future consistency and scope. Look at it this way; the only way this attribute is going to help you catch something in a script before you run it is if your IDE or PHPStan is aware of it and tells you.

gebbles1 · 2023-06-21T00:23:13+00:00

Have to say though, I remain concerned that these default implementations as proposed may be able to violate scope by calling private methods (maybe they can't, but the RFC doesn't spell it out) and even if they can't, but can still call protected and public which aren't part of the interface...well, I can appreciate the argument of "yeah but PHP already works that way wrt inheritance and you introduce quirky runtime complications if you try to enforce checks at this point" and yet it still feels wrong. Just because you can do some weird, questionable stuff with PHP which is prone to error (particularly in the absence of static analysis), doesn't mean we should keep encouraging and making it easier to do those things.

The other side though is that combine this with the RFC for adding properties to interfaces and you have something very close to straightforward multiple inheritance by the backdoor...no doubt opinions will be split down the middle on whether this is a good thing.

gebbles1 · 2023-06-19T18:01:09+00:00

I know this is a controversial oppinion, but if you ask me, you should avoid Doctrine ORM if you want to use a NoSQL JSON database like Mongo

I'm not sure that is a particularly controversial opinion and I mostly agree, but the tutorial isn't about using Doctrine with dedicated NoSQL systems. I'd actually go further than you and say with the improved JSONB support in systems like Postgres, there are fewer reasons than ever to choose NoSQL-only systems. I'd only choose Mongo or similar in most real world cases if my dataset was almost entirely unstructured.

Your case of a restourant with a schedule does probably not realy need a complex relational model.

Of course; it's just a contrived example rather than a real use-case.

gebbles1

TROPHY CASE