Include camel case attribute version

[edvordo]

Summary

When model attribute is defined as either one of these

public function getSomeValueAttribute() 
{
    return 'some value';
}

public function someValue(): Attribute 
{
    return Attribute::get(fn () => 'some value');
}

it is also possible to access the attribute via its camel case form, a.k.a

$post = Post::first();
// both output the same value based on the attribute configuration
// in the case of the above example: "some value"
$post->some_value;
$post->someValue;

I am aware of model_camel_case_properties config option, but I don't want to have all attributes camel cased, just attributes.

Having this option improved the navigation to attributes, at least in my code base (don't have a publicaly facing repo to showcase, sorry).

Decided to add a configuration option for this and it's off by default, so existing projects would not have their models' DocBlocks populated with the camelCase version of attributes, but if this is deemed as too much, I am happy to remove it.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• Existing tests have been adapted and/or new tests have been added
• Code style has been fixed via composer fix-style

[edvordo]

Anything I can do to get this merged?
Happy to close, if this is something that you don't wanna add, of course.

[barryvdh]

Why would you need both variants?

[edvordo]

Good question, I technically don't need both.
I can update the PR to make this a toggle between the two.
Or make it a three way setting, a.k.a. one of just snake case, just camel case or snake and camel case.

Or, as I said, I can close the PR, as in the month since I made it I've resorted to a model hook, that handles a very narrowed down version of this PR.

[mfn]

PoV: hooks were introduced to give power to people to handle their special cases, as IMHO it doesn't make sense to provide all the options under the sun in a single package then no one else ever needs.

If hooks are missing something, maybe we can improve / refactor the code to allow supporting hose cases better.

All IMHO :)

[edvordo]

I mean, if you willing to make a few of the model command methods public, so that I won't have to reimplement the wheel, that would be helpful.

These are some of the methods I could make use of:

• getReturnTypeFromReflection
• getAttributeTypes

Alternatively, there could be something similar to model hooks, but it would trigger for all props being added and it would get passed the full prop definition (name, return types, read, write, ..) so that i could just take it and make the modifications needed.

I don't know which you'd be okay with, might be neither and you may have a better idea, I'm just brainstorming.

[edvordo]

Any kind of feedback would be welcome as to which direction I should take this. I don't want to spend time implementing something that is not desirable for you.