Add support for custom morph class resolvers

[misenhower]

Hey there! This PR adds an optional resolveUsing setting to the morph map generator.

This is a similar idea to what was proposed in #3, but enables users to customize how the "default" alias is resolved by providing a callback.

For instance, you could base the morph names off the table name for each model like this:

MorphMapGenerator::resolveUsing(fn ($model) => Str::singular($model->getTable()));

This would generate names like post or comment depending on the model's table name in the DB (which should be pretty stable even if you rearrange your model classes). This is just an example though, and you could add whatever logic you might want there.

Let me know what you think. Thanks!

[freekmurze]

Thanks! Could you also mention this feature in the readme and a clear example?

[freekmurze]

I think it would be nice to support having the resolveCallback returning null. When null is returned, we could fallback to getMorphClass

[rubenvanassche]

Thanks for the PR but I don't think is a feature we want to add? The whole point of a morph map is setting things in stone, with this PR you allow things that can be changed to be used as morph keys and thus your morph map won't be stable again.

In you example, the table name can be changed at a point in time and thus there is no validity in your morph map. This example is indeed quite stable, but it happens that your table names change. That will be quite a nasty bug to find would this happen.

What do you think @freekmurze?

[freekmurze]

I'm always up for a little flexibility, but I agree there's value in following the strict spirit of this package, and pass up on this.

[misenhower]

My thinking is: if you're changing a DB table name, you're already making significant changes to your DB, so you'd probably expect to have to make changes to things like this as well.

There's a lot of functionality in Laravel that derives table/column names from class names, method names, etc. so IMO this fits in with the overall Laravel "philosophy" but I understand your concerns as well :) It's an opt-in feature though, so anyone with concerns about stability wouldn't have to use it.

In any case, I've made the requested changes in case you do choose to merge this. Thanks!!

[rubenvanassche]

Let's merge it in with a strong warning 😄

[rubenvanassche]

Thanks

[misenhower]

Hey, thanks for merging this! Much appreciated 😃