Special getter / setter / hasser cases for ordered_class_elements

[soullivaneuh]

I like the ordered_class_elements class fixer, but I would like to keep "pure" getters, setters and hassers at the end of my class, whatever the public / protected / private order definition.

Maybe could we add hierarchy options for that?

[keradus]

for me, it's too specific, 👎 unless you provide nice, generic solution

[soullivaneuh]

Having getters, setters and hassers option for function directly "linked" to the property is the more generic way IMHO.

Or I didn't understand your question. 😉

[TomasVotruba]

@soullivaneuh I think question was: how would you solve that?

[soullivaneuh]

@TomasVotruba Not sure to understand your question.

I talked about the option. After that I can work on some POC to see what is possible.

[TomasVotruba]

@soullivaneuh It's been a while for me. I guess I was curious about specific approach that would make sense.

I'm personally fine with public/protected/private, ordered by use order.

E.g. while 1st public method uses 2 private methods, they should be in top of private methods.

[keradus]

big 👎 for that.
then, other public method would use that private, and code would be rearrange because of that :/

[TomasVotruba]

Nono, I don't want a fixer for that 👍 I'm fine with my hands and AI 😄

[soullivaneuh]

What about keeping the default behavior and propose this as option? If you don't want to add exception, just don't activate them?

[keradus]

then #2746 (comment)

[Wirone]

It would be better if #6360 (or subsequent PR based on it) could provide wildcard support for custom order, so you could use method:get*, method:set* and method:has* at any place you want. Other than that, I'm with @keradus and 👎 for any non-flexible solution.

[Wirone]

I am going to close this because it's 6 years old and did not get enough traction. Let's sum it up:

• only generic solution might me accepted
• there's already support for custom method placement and it's a good starting point to provide support for wildcards
• it's out of the scope of core team's focus, so keeping issue open does not make sense, but if anyone wants it, we're open for a PR