My opinion on the PHP 8.1 Enum RFC

RVxLab — Sat, 30 Jan 2021 13:16:09 +0000

TL;DR

The basic and backed enums of this RFC are a nice implementation of enums in PHP, but in its current form it simply does too much.

Foreword

Yesterday Brendt from Spatie posted a blog post about new things in PHP 8.1. The one things that caught my eye was enums and since I've been wanting them in PHP for quite a while now I got a bit excited to say the least.

Reading the RFC started good and well but the further I went, the more I disliked it.

Basic enums

The basic enum implementation of this RFC looks like so:

enum Suit {
  case Hearts;
  case Diamonds;
  case Clubs;
  case Spades;
}

Using case to denote an enum value is slightly odd, but I'll take it. If it would be possible I believe it'd be better to omit this all together:

enum Suit {
  Hearts;
  Diamonds;
  Clubs;
  Spades;
}

Backed enums

Backed enums very much remind me of enums in TypeScript which are incredibly useful. Having this in PHP is very nice indeed.

enum Suit: string {
  case Hearts = 'H';
  case Diamonds = 'D';
  case Clubs = 'C';
  case Spades = 'S';
}

This feature alone would likely cause me to drop myclabs/php-enum as my enum implementation.

No mixing

Backed enums and Basic (or Pure) enums cannot be mixed together, so something like this is not allowed:

enum Suit: string {
  case Hearts = 'H';
  case Diamonds = 'D';
  case Clubs;
  case Spades;
}

I completely agree, otherwise it would just turn into a giant mess.

Enum methods

This is the point where the RFC lost me. I understand that having methods in an enum. Hell, in some cases I add a random() method in enum classes made with myclabs/php-enum. But that's usually as far as I'm willing to go.

If you need to add an interface or trait to an enum, why not just use a class instead?

The examples list extra information you can list with an enum, but doesn't that just beat the whole point of making enums to begin with?

Closing thoughts

I'd be incredibly happy if this RFC got accepted, enums are something that PHP can really use. Unfortunately, this implementation just does too much and it wouldn't surprise me if it got rejected on that basis.

However, should it be accepted, I'll be unlikely to use those enum methods.

Thanks for reading. This was my first proper post on this site and I'd like to improve my writing skills.

Any feedback on this post is greatly appreciated.

Dealing with 100vh on iOS Safari in TailwindCSS

RVxLab — Fri, 22 Jan 2021 11:32:33 +0000

Recently I've been needing to develop for iOS Safari, in which I found out that 100vh is not quite 100vh on there.

Now, there are fixes for this. Namely by using height: -webkit-fill-available, as demonstrated here. This however has the unfortunate side effect of also targetting Chromium-based browsers.

To fix that you can check for the support of -webkit-touch-callout: none. With that, only iOS and iPadOS Safari are targetted.

In order to make this much easier to use in Tailwind I created a plugin for it.

You can find the plugin here: https://www.npmjs.com/package/@rvxlab/tailwind-plugin-ios-full-height

DEV Community: RVxLab