SkipBackplaneNotifications naming

[MrLesk]

Hi. First of all, naming is hard and no name is 100% perfect for all use cases so feel free to completely object my proposal.

SkipBackplaneNotifications is such a hard name for me. Whenever I read the code I'm like this:

I would have a much easier time if the name of the property would say what the functionality will do instead of what it will not do (do not skip notifications -> send notifications)

If at this time you are still not hating me then you might consider some aliases:

• EnableBackplaneNotifications
• SendBackplaneNotifications

[jodydonetti]

Hi. First of all, naming is hard and no name is 100% perfect for all use cases so feel free to completely object my proposal.

Ahah, naming things, here we go.

SkipBackplaneNotifications is such a hard name for me. Whenever I read the code I'm like this:
I would have a much easier time if the name of the property would say what the functionality will do instead of what it will not do (do not skip notifications -> send notifications)

I know very well that feeling, so I'd like to explain why I picked "skip" (if you can believe me, I thought a lot about it 😅).

First thing: what does the system normally do? Send backplane notifications (if configured).
So what you want to say in some cases is to skip them.

Sure, we can talk for years about "EnableFoo" with a default value of false VS "DisableFoo" with a default value of true... been there done that with multiple teams for hours and hours 🤣 ... but here the concept of "skipping" what normally happens wins. At least that was my reasoning (which ca be wrong, mind you).

Second thing: you can already skip L1 and/or L2: again, normally they are used, and if you want you can opt-into skipping them, which is the exception.

Last thing: for me, consistency rules.

If A is right and B is wrong, of course choose A. Easy.

But if A is right and B is also right and I just slightly prefer A but there are already other cases of similar-to-B around, then I'd go with B. Again, consistency. It lowers the cognitive burden by always being "the same".

So to recap we have:

• SkipMemoryCacheRead
• SkipMemoryCacheWrite
• SkipDistributedCacheRead
• SkipDistributedCacheWrite
• SkipBackplaneNotifications

I like the uniformity here.

If at this time you are still not hating me then you might consider some aliases:

• EnableBackplaneNotifications
• SendBackplaneNotifications

I don't like to add them, this will create confusion for all the other users.

BUT!

If you really have a hard time making sense of it, you can create a couple of ext methods on FusionCacheEntryOptions with those name! I will not hide that in the past I've made a couple of similar things myself with other libraries (but, to be honest, I always felt 50/50 regarding feeling more "intuitive for me", but also maybe "less intuitive for others in the team" or "having 2 different methods for the same thing"... so...)

Hope this helps, let me know!

[MrLesk]

Thank you. I really appreciate the time you put for this explanation.

In my case the problem comes from the lack of distributed cache (I'm the "hey ma! look! no l2 cache" guy). So all the names in my case are inverted because I am skipping notifications by default.

The extension is actually a good solution. Got so confused by the name that I could't think about something as simple as this

[jodydonetti]

In my case the problem comes from the lack of distributed cache (I'm the "hey ma! look! no l2 cache" guy). So all the names in my case are inverted because I am skipping notifications by default.

Ah, got it.

Also:

I'm the "hey ma! look! no l2 cache" guy

Watch out for that scenario, it can be really "delicate". I added a couple of warnings in the logs for that, I hope they may have been useful.