Wouldn't it be a cool idea to add to the "get" functions capital functions in the juce codebase?

Hi,

I think its much nicer to read

file.FullPathName()

than the old-school get style:

file.getFullPathName()

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 ( :smile: ) and the capital style could be added?

+1 for my idea :wink:

Best equinox

No it wouldn’t :wink:

8 Likes

Ouch.

2 Likes

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 :slight_smile:

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.

1 Like

I am not so much opposed of losing the get part. I don’t mind either way.

  • My aesthetic opinion towards capital functions is: please don’t.
  • Don’t have two functions doing the same thing (even if you use using Foo=getFoo;
    (btw. you can do that in your codebase)
  • I agree with @HowardAntares : get != take
  • last but not least: if you want to express that the state was not changed, there is const
3 Likes

Feels like arguing with pure C++ coders to not use m_ on members :slight_smile:

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).

1 Like

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.

4 Likes

Good example, this makes somehow sense to me.
Anyway I would argue, there is still some friction with the other means of get.

What if someone tells you to “get the f*** out of here with this idea”? :joy:

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.

GetFullPathName FullPathName 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”. :face_vomiting:

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. :joy:

1 Like

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.

2 Likes

We haven’t had a complaint about JUCE’s use of British-English with Colour etc. for a while, anyone feeling it tonight? :joy:

8 Likes

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’. :face_with_raised_eyebrow:

4 Likes

Good, next use the metric system. Good to see people improving themselves, regardless of what struggle they were born with.

6 Likes

hah-hah. :laughing: Never.

1 Like

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. :wink:

2 Likes

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. :grin:

4 Likes

Everybody that tried to be funny / sarcastic / cyncial:
I want to give you the advice to overthink your mindset in general.

1 Like

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.

I thought there was some merit to that.

Then switched back to camelcase.

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).

Yepp, triggered :wink:

1 Like