With get it means you take something, that changes the state of another thing. But get how it is used does not change anything so the other style is more logical.
I know for old things to work this would be a horror, but old function could stay there for some 5-10 years ( ) and the capital style could be added?
If you get a beer in a bar, you change the state of the bar: it has less beer that it owns than before, but it has more money.
The âgetâ how it is used in programming does not change any state, so thatâs why there is an objective true reason for not using get
Nothing about âgetâ implies âtake away fromâ. Just because there is a way to interpret the word âgetâ in some context to mean âtake away fromâ, thatâs not how getters are defined in the programming world.
Feels like arguing with pure C++ coders to not use m_ on members
OK get is not take, but all sentences that came into my mind with get made no sense as an analogy (and saying yeah than itâs a definition implicitly agrees, that the analogy itself is weak).
Well, you might ask someone âget me their phone number, will youâ? Theyâre not taking the other personâs phone number away, theyâre just getting you some information.
What if someone tells you to âget the f*** out of here with this ideaâ?
Seriously though, there are many ways to interpret what âgetâ means.
In the end I think itâs about context (as with all language), and in the context of C++ you often have âgettersâ and âsettersâ, so it follows that they would be paired. eg. getFullPathName and setFullPathName.
GetFullPathNameFullPathName and SetFullPathName just looks like it wouldnât be out of place in Java or some other such god-awful horrific shite, and just feels weird to not have the âsymmetryâ.
Iâve never understood this, it smacks of Hungarian Notation and even in the mid-1990s when I was studying CS at university they were telling us that that was to be strongly avoided. Although not quite as strongly as Linus Torvalds, who called it âbrain damagedâ to use in typed languages.
How many experienced coders have to tell you that you have it wrong? There are literally millions of coders out there that have been using getters and setters for decades. There even is a name for the concept, âgettersâ and âsettersâ. Some languages have built-in getters and setters for public properties, etc.
Arguing against something commonly used by everyone is not a productive use of anybodyâs time. You might as well argue that JUCE shouldnât use English for itâs function-names because you like Mandarin better. Itâs equally as wrong and pointless.
The weird part about that is Iâve started using âcolourâ in everyday written text (Iâm American)⊠not to mention I now find myself typing âbehaviourâ.
my country uses the British âColourâ, but I still type it "Colorâ every dam time. Then squint at it for a while before I slap my forehead. I guess Iâve subconsciously learned to code in American English.
It is a good idea! I have few monthes free to change all my JUCEd projects for that critical improvement. And it seems that currently the JUCE team is idle ; that would be a nice hobby to fill their work days.
I know it triggers peopleâs OCDs, but one argument where I used to work at was that capitalized function names make it easy to differentiate between own and juce methods.
Thatâs the argument of where I work now as well. If that is important, then I think prefixing or proper use of namespaces serves that purpose better.
I hate it every day there. I always have to write my methods twice because I write them lower case first.
Donât forget, you donât type your own methods, you type juce methods as well when you use them, so muscle memory wouldnât work at all.
And in an ideal world you donât care if it is your or their method (or the other ones, if you have more than two codebases wielded together).