Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork1.2k
Include camel case attribute version#1676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Include camel case attribute version#1676
Uh oh!
There was an error while loading.Please reload this page.
Conversation
edvordo commentedMar 17, 2025
Anything I can do to get this merged? |
barryvdh commentedMar 17, 2025
Why would you need both variants? |
edvordo commentedMar 17, 2025
Good question, I technically don't need both. 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 commentedMar 17, 2025
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 commentedMar 19, 2025
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:
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 commentedJun 28, 2025
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. |
Uh oh!
There was an error while loading.Please reload this page.
Summary
When model attribute is defined as either one of these
it is also possible to access the attribute via its camel case form, a.k.a
I am aware of
model_camel_case_propertiesconfig 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
Checklist
composer fix-style