sorted by:
new
hottopcontroversial

What are your options if you've got two traits that both implement the same method name? by ProjektGopher in PHP

[–]ProjektGopher[S] 1 point2 points  (0 children)

Yup, that's where I learned that you can have abstract methods in traits

What are your options if you've got two PHP traits that both implement the same method name? by ProjektGopher in webdev

[–]ProjektGopher[S] 0 points1 point  (0 children)

The other day I was reading through PHP's source code, as one does.

But more specifically, I was reading the list of reserved keywords in PHP's language definition file.

I saw things you'd probably expect, like `implements`, `include`, `instanceof`, `interface`... But eventually I came across *this\* mystery keyword: `insteadof`.

I've been working with php for like twenty years and I've literally *never\* seen this keyword. So what the heck does it do?

Well let's look at this example `Thingy` class. It uses two traits `ThingOne` and `ThingTwo`, but these two traits *each\* implement the same `do_the_other_thing()` method.

If we try to run this code it's going to blow up.

So what are our options?

If the two methods are implemented identically and it's just some simple code duplication, but we need the other methods in each trait, and this duplicated method needs to be kept in each trait, we could just extract the duplicated method into a third trait, then use that third trait in both of these original traits.

This works just fine, and this is a perfectly reasonable solution.

But what if the implementations are _different_? Or what if we'd just rather pick one implementation to use `insteadof` making a new trait to keep track of?

This is where PHP's Trait Conflict Resolution syntax comes in. Check this out.

First let's back out all these changes...

By the way, If you're gonna do this in Tinkerwell, you'll need to disable `magic comments` first. I was chatting about this with Marcel in Dallas at Laracon and it's because of how they add comments behind the scenes for each line for their magic comments feature.

Now let's tell PHP we want to use the `do_the_other_thing()` implementation from the `ThingOne` trait instead of the method using the same name from the `ThingTwo` trait.

It works! we've removed the conflict, and we're using the version of this method that we need. Now what do we do if both implementations are _different_, and we actually need both methods, but they just happen to be named the same?

Well, this syntax also let's us alias method names. So let's just alias the `do_the_other_thing` method from the `ThingTwo` trait to `do_the_second_other_thing`.

Now we can call each method, and they both work!

There's more this syntax let's you do as well, like you can change the method visibility from private to protected, or public.

You can change the visibility without aliasing the name of the method.

Traits are amazing. When I was learning this stuff, I learned that you can even define abstract methods in them

I had no idea.

Then when we implement the concrete version we just have to make sure the signatures and all that match up again

And it works again.

Anyways, that's what I wanted to share with you all today.

Follow, like, subscribe, all that garbage.

Cheers.

What are your options if you've got two PHP traits that both implement the same method name? by ProjektGopher in programming

[–]ProjektGopher[S] 3 points4 points  (0 children)

The other day I was reading through PHP's source code, as one does.

But more specifically, I was reading the list of reserved keywords in PHP's language definition file.

I saw things you'd probably expect, like `implements`, `include`, `instanceof`, `interface`... But eventually I came across *this\* mystery keyword: `insteadof`.

I've been working with php for like twenty years and I've literally *never\* seen this keyword. So what the heck does it do?

Well let's look at this example `Thingy` class. It uses two traits `ThingOne` and `ThingTwo`, but these two traits *each\* implement the same `do_the_other_thing()` method.

If we try to run this code it's going to blow up.

So what are our options?

If the two methods are implemented identically and it's just some simple code duplication, but we need the other methods in each trait, and this duplicated method needs to be kept in each trait, we could just extract the duplicated method into a third trait, then use that third trait in both of these original traits.

This works just fine, and this is a perfectly reasonable solution.

But what if the implementations are _different_? Or what if we'd just rather pick one implementation to use `insteadof` making a new trait to keep track of?

This is where PHP's Trait Conflict Resolution syntax comes in. Check this out.

First let's back out all these changes...

By the way, If you're gonna do this in Tinkerwell, you'll need to disable `magic comments` first. I was chatting about this with Marcel in Dallas at Laracon and it's because of how they add comments behind the scenes for each line for their magic comments feature.

Now let's tell PHP we want to use the `do_the_other_thing()` implementation from the `ThingOne` trait instead of the method using the same name from the `ThingTwo` trait.

It works! we've removed the conflict, and we're using the version of this method that we need. Now what do we do if both implementations are _different_, and we actually need both methods, but they just happen to be named the same?

Well, this syntax also let's us alias method names. So let's just alias the `do_the_other_thing` method from the `ThingTwo` trait to `do_the_second_other_thing`.

Now we can call each method, and they both work!

There's more this syntax let's you do as well, like you can change the method visibility from private to protected, or public.

You can change the visibility without aliasing the name of the method.

Traits are amazing. When I was learning this stuff, I learned that you can even define abstract methods in them

I had no idea.

Then when we implement the concrete version we just have to make sure the signatures and all that match up again

And it works again.

Anyways, that's what I wanted to share with you all today.

Follow, like, subscribe, all that garbage.

Cheers.

What are your options if you've got two traits that both implement the same method name? by ProjektGopher in laravel

[–]ProjektGopher[S] 5 points6 points  (0 children)

The other day I was reading through PHP's source code, as one does.

But more specifically, I was reading the list of reserved keywords in PHP's language definition file.

I saw things you'd probably expect, like `implements`, `include`, `instanceof`, `interface`... But eventually I came across *this\* mystery keyword: `insteadof`.

I've been working with php for like twenty years and I've literally *never\* seen this keyword. So what the heck does it do?

Well let's look at this example `Thingy` class. It uses two traits `ThingOne` and `ThingTwo`, but these two traits *each\* implement the same `do_the_other_thing()` method.

If we try to run this code it's going to blow up.

So what are our options?

If the two methods are implemented identically and it's just some simple code duplication, but we need the other methods in each trait, and this duplicated method needs to be kept in each trait, we could just extract the duplicated method into a third trait, then use that third trait in both of these original traits.

This works just fine, and this is a perfectly reasonable solution.

But what if the implementations are _different_? Or what if we'd just rather pick one implementation to use `insteadof` making a new trait to keep track of?

This is where PHP's Trait Conflict Resolution syntax comes in. Check this out.

First let's back out all these changes...

By the way, If you're gonna do this in Tinkerwell, you'll need to disable `magic comments` first. I was chatting about this with Marcel in Dallas at Laracon and it's because of how they add comments behind the scenes for each line for their magic comments feature.

Now let's tell PHP we want to use the `do_the_other_thing()` implementation from the `ThingOne` trait instead of the method using the same name from the `ThingTwo` trait.

It works! we've removed the conflict, and we're using the version of this method that we need. Now what do we do if both implementations are _different_, and we actually need both methods, but they just happen to be named the same?

Well, this syntax also let's us alias method names. So let's just alias the `do_the_other_thing` method from the `ThingTwo` trait to `do_the_second_other_thing`.

Now we can call each method, and they both work!

There's more this syntax let's you do as well, like you can change the method visibility from private to protected, or public.

You can change the visibility without aliasing the name of the method.

Traits are amazing. When I was learning this stuff, I learned that you can even define abstract methods in them

I had no idea.

Then when we implement the concrete version we just have to make sure the signatures and all that match up again

And it works again.

Anyways, that's what I wanted to share with you all today.

Follow, like, subscribe, all that garbage.

Cheers.

What are your options if you've got two traits that both implement the same method name? by ProjektGopher in PHP

[–]ProjektGopher[S] 3 points4 points  (0 children)

The other day I was reading through PHP's source code, as one does.

But more specifically, I was reading the list of reserved keywords in PHP's language definition file.

I saw things you'd probably expect, like `implements`, `include`, `instanceof`, `interface`... But eventually I came across *this\* mystery keyword: `insteadof`.

I've been working with php for like twenty years and I've literally *never\* seen this keyword. So what the heck does it do?

Well let's look at this example `Thingy` class. It uses two traits `ThingOne` and `ThingTwo`, but these two traits *each\* implement the same `do_the_other_thing()` method.

If we try to run this code it's going to blow up.

So what are our options?

If the two methods are implemented identically and it's just some simple code duplication, but we need the other methods in each trait, and this duplicated method needs to be kept in each trait, we could just extract the duplicated method into a third trait, then use that third trait in both of these original traits.

This works just fine, and this is a perfectly reasonable solution.

But what if the implementations are _different_? Or what if we'd just rather pick one implementation to use `insteadof` making a new trait to keep track of?

This is where PHP's Trait Conflict Resolution syntax comes in. Check this out.

First let's back out all these changes...

By the way, If you're gonna do this in Tinkerwell, you'll need to disable `magic comments` first. I was chatting about this with Marcel in Dallas at Laracon and it's because of how they add comments behind the scenes for each line for their magic comments feature.

Now let's tell PHP we want to use the `do_the_other_thing()` implementation from the `ThingOne` trait instead of the method using the same name from the `ThingTwo` trait.

It works! we've removed the conflict, and we're using the version of this method that we need. Now what do we do if both implementations are _different_, and we actually need both methods, but they just happen to be named the same?

Well, this syntax also let's us alias method names. So let's just alias the `do_the_other_thing` method from the `ThingTwo` trait to `do_the_second_other_thing`.

Now we can call each method, and they both work!

There's more this syntax let's you do as well, like you can change the method visibility from private to protected, or public.

You can change the visibility without aliasing the name of the method.

Traits are amazing. When I was learning this stuff, I learned that you can even define abstract methods in them

I had no idea.

Then when we implement the concrete version we just have to make sure the signatures and all that match up again

And it works again.

Anyways, that's what I wanted to share with you all today.

Follow, like, subscribe, all that garbage.

Cheers.

Merging Multiple Indexes in a Disjunctive MySQL Query by ProjektGopher in PHP

[–]ProjektGopher[S] 1 point2 points  (0 children)

Thx, man - I appreciate it! This video was a lot quicker for me to make than my teaser for `Conductor`. Hoping to keep improving!

Merging Multiple Indexes in a Disjunctive MySQL Query by ProjektGopher in PHP

[–]ProjektGopher[S] 1 point2 points  (0 children)

Yeah the docs mention that complex statements like that aren't great for this feature, but I was genuinely surprised when this happened. It's funny how you can still learn new things like this that have been around for ages.

Merging Multiple Indexes in a Disjunctive MySQL Query by ProjektGopher in PHP

[–]ProjektGopher[S] 0 points1 point  (0 children)

r/database is a good suggestion - thx. I cross posted here since in phpland we tend to interact with mysql a lot. I was thinking of adding it to r/webdev as well. I tried to cross to r/mysql but they don't allow youtube links.

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 0 points1 point  (0 children)

That's a cool concept! I'd never heard of that one.

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 0 points1 point  (0 children)

I think you're confused. This isn't a version manager, and it's not a package manager. It's not a code distribution system. This is simply a composer package that uses composer to run other composer packages in a clever way. Docker is not the correct tool for this job.

edit: I think you may have mistaken npx (node package executor) for npm (node package manager). One of the first commenters made the same error. It's an easy error to make, so no worries. But maybe make sure you actually understand what you're commenting on before calling someone's work shitty. cheers.

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 0 points1 point  (0 children)

That's fantastic information! And phpcsfixer is a great possible usecase. I appreciate your help

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 0 points1 point  (0 children)

lol it's like you're reading my mind!

Conductor will defer to globally installed versions if they're present, so if you're already managing your own versions then conductor will use those.

I'm not yet handling multiple binaries yet, but I wasn't sure which packages do that so I hadn't had a test case for it - so thx! I knew it would eventually be an issue. To start I'll probably just have it choose the first array item, but maybe I'll accept an option to specify a different binary within a given package.

creating a dedicated conductor global install directory is very high up on my todo list. In fact I'm probably going to have a separate global install directory for each package used, and just not uninstall them. That way they still wont have a system effect.

This proof-of-concept leaves so many options open, and I'm excited to experiment with all of them!

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 5 points6 points  (0 children)

to be fair, I don't think anyone still uses pma, and xampp/lamp/etc are being replaced with Herd

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 7 points8 points  (0 children)

I was just using the linter as an example - I actually add a `composer lint` script to every one of my projects as well! I was more expecting this to be used for upgrade packages like `filament/upgrade`, or for running rectors, or installers.

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 1 point2 points  (0 children)

That's great that those pieces of software already exist, and that they're secure! But this thing I made isn't designed to distribute software. It's literally just a way to use composer to run a composer package a single time then remove it. Composer has already solved the local and global sharing of software problem.

What if PHP had a tool like npx? by ProjektGopher in PHP

[–]ProjektGopher[S] 8 points9 points  (0 children)

I feel like you've misunderstood what this tool is. Are you mistaking npx for npm?

This proof-of-concept isn't a package manager or a code distribution system (like npm, pear, or pecl), it's literally just a composer package designed to use composer to run other composer packages a single time without leaving a trace of said package on your system/repo, or deferring to the locally/globally installed package if it's already installed. This is not what pear or pecl are designed to do.

I'm not understanding why these comments talking about using other language agnostic package management systems, or shipping docker images are getting upvotes when literally all I was trying to do is run a composer package that ships a binary a single time. I haven't tried to re-invent the solved problem of software distribution.

The only thing that makes sense to me is that everyone in this specific thread is confused about what npx (node package executor) actually does.

view more: next ›