Why shouldn't parameters be public?

[tidyui]

I'm building a composite application where you register the different fields your data-models can use at startup.

RegisterField<T>() where T : IField

As a result you also need to register the component that should handle the field in the Blazor App. To make sure that the component provides that basic functionality needed by the generic part of the app I want the component to also implement an interface using the @implements keyword.

RegisterFieldComponent<T> where T : IFieldComponent

Naturally I want to include the mandatory parameters these components need to have for them to function but then the compiler throws a warning telling me that parameters shouldn't be public. As I can't get a good night sleep with compiler warnings in my projects this only leaves with the option to use an abstract base class instead of an interface but this feels a bit dodgy as I'm not really encapsulating any logic, I only want the components to fulfill a certain contract.

What is the reason for the warning that parameters shouldn't be public? Help me get a good night sleep with a good motivation 😀

Best regards

[SteveSandersonMS]

To have a clear mind about this, you have to recognize the distinction between parameters, which are how data flows down the component hierarchy and is integrated into the rendering system, and properties, which are just a C# concept and have no way of interacting directly with the rendering system.

• You can make your properties have whatever access rules you want. They are just C# properties. Do what you like.
• For anything you declare as a parameter (by adding [Parameter]), you're saying it's an aspect of the rendering system. It should only be mutated by the rendering system, or you'll get out of sync and confused.

So, I think we should tweak the analyzer rule to have it warn only if the parameters are publicly settable. There's no problem with them being publicly readable. They just shouldn't be publicly writable (because if they are, you're inviting others to mutate them, even though this will get you out of sync and make your app seem buggy).

In your specific example, an abstract base class sounds like a good fit. An interface wouldn't be sufficient because it can't enforce the presence of [Parameter].