Is this hiding behavior as intended?

[NielsHoogeveen]

I'd like to have classes with variants in which some properties can be null, and variants where they can't be null.

I have been playing around with the "new" keyword to hide a nullable version of a property and provide a new one that cannot be null.

When overriding a base class that has this property as nullable with a "new" property that cannot be null, leads to null value of the orginal property.

This is demonstrated by class D in the following example. When I create an instance of that class, the Value parameter is set. When assigning that variable to a variable of the type I1 (where the Value property is nullable), then the Value is null.

However, when I introduce an interface I2, which hides the nullable property Value of I1 and implement that interface in class C, the Value property of an instance of C always has a not null value, even when addressed as an I1.

I am pleased that I can create nullable and not nullable variants of classes this way, but I am not sure if this is the intended behavior of C#. I'd like to use this pattern, but only if there is a guarantee that a future version of C# still behaves the way it is doing now.

BTW. this works identical under net7.0 and net8.0.

internal class Program
{
    static void Main(string[] args)
    {
        I1 res1 = new C { Value = "hello world!" };
        var res2 = new D { Value = "hello world!" };
        I1 res3 = res2;
        Console.WriteLine(res1.Value is null); //False
        Console.WriteLine(res2.Value is null); //False
        Console.WriteLine(res3.Value is null); //True
    }
}

//Define an interface with a nullable string value
public interface I1
{
    string? Value {get;}
}

//Hide the nullable string property and replace it with one that cannot be null
public interface I2: I1
{
    new string Value { get; }
}

//Introduce a base class that provides an implementation of the nullable Value property
public abstract class A: I1
{
    public string? Value { get; set; }
}
//Extend class A, hide the nullable Value property with one that cannot be null
public class D: A
{
    public required new string Value { get; set; }
}
//Extend class A, hide the nullable Value property with one that cannot be null, AND implement I2
public class C : A, I2
{
    public required new string Value { get; set; }
}

[iam3yal]

@NielsHoogeveen

I'd like to have classes with variants in which some properties can be null, and variants where they can't be null.

When you want to have things but not needing them it's where you can save yourself a lot of troubles.

I am pleased that I can create nullable and not nullable variants of classes this way, but I am not sure if this is the intended behavior of C#. I'd like to use this pattern, but only if there is a guarantee that a future version of C# still behaves the way it is doing now.

This probably wouldn't break in future releases but really not something you want to use as a pattern, imo you're making something extremely simple relatively complicated, the new keyword is intended to be used when you generally don't control the code (3rd-party) and need to derive from a class but now need to use the same name to shadow the old member in your derivation because the name just makes sense so I'd say using new should be the exception and not the rule.

Another point is you're making hierarchies or design your code solely based on whether something is nullable, your making something that should trivial to decide a relatively hard choice.

If you need to support both nullable and non-nullable members you can just define your interface like this:

public interface I1
{
    string Value {get;}
    
    string? GetValueOrDefault();
}

Just to show you another example/alternative is doing something like this:

public interface I1
{
    string? Value {get;}
    
    public string GetValueOrEmpty() 
        => Value is null ? string.Empty : Value;
}

Hope it helps.

[NielsHoogeveen]

If it's doing all that pattern matching and tyep checking anyways, i don't see the aversion to just using separate types :)

I opened this discussion to ask about a language behavior of C# that I have not seen documentented (or at least I couldn't find the documentation that described it in terms that I could understand).

I much rather receive confirmation that this behavior is indeed as intended or that I have stumbled upon unintended behavior that might change in the future. Whether using this behavior is a good idea was never my intention of discussing.

I am still awaiting an answer to my initial question that goes beyond, "likely not to change soon".

[CyrusNajmabadi]

Whether using this behavior is a good idea was never my intention of discussing.

The reason for this part of the discussion is not to critique your idea, but to explain the thinking into why things work the way they do. :)

I am still awaiting an answer to my initial question that goes beyond, "likely not to change soon".

WRT whether htis is working "as intended" or not. The answer is 'yes', this is as intended.

[NielsHoogeveen]

Whether using this behavior is a good idea was never my intention of discussing.

The reason for this part of the discussion is not to critique your idea, but to explain the thinking into why things work the way they do. :)

I am still awaiting an answer to my initial question that goes beyond, "likely not to change soon".

WRT whether htis is working "as intended" or not. The answer is 'yes', this is as intended.

Now I am confused.

If the hiding behavior as I described in the original question is as intended, then the usage pattern fits with why things work the way they do, otherwise it would be unintended behavior.

There are clearly advantages to using the pattern, because it allows for encoding nullability information using a common type. This encourages code reuse. The other options require either code duplication or loss of information (defensively assuming nullability even when this is not the case).

[CyrusNajmabadi]

If the hiding behavior as I described in the original question is as intended,

The hiding works as we intended it to based on just how hiding works in the language since v1. Your use case in terms of how you use it is not something i would personally recommend. There's no connection between the fact that it works for you, and the idea that it's a good idea.

[NielsHoogeveen]

If the hiding behavior as I described in the original question is as intended,

The hiding works as we intended it to based on just how hiding works in the language since v1. Your use case in terms of how you use it is not something i would personally recommend. There's no connection between the fact that it works for you, and the idea that it's a good idea.

What are the criteria for a good idea?

Every engineering solution has trade offs and so do the options we have in this use case. Let me sketch the logical options we have in this scenario.

We have two types I1 and I2. Where I2 contains the same properties as I1, but some of the properties in I1 are nullanble where they are not nullable in I2. Let's initially assume that I1 and I2 are unrelated.

We have a service that processes view models which received type I2.

We have a user interface that has a validation method that should produce I2, so a call can be made to the processing service.

We have a service that creates view models, where we have a view model for new entities and we have a view model for existing entities. The view model for new entities will be of type I1. The view model for existing entities can either be of type I1 (where we lose information that some properties are in fact not nullable), or of type I2.

There are three options as far as I can tell.

1. Split UI's
   The create view model service creates an I1 for new entities and an I2 for existing entities. We create a UI component for I1 and a separate UI component (with mostly the same functionality) for I2. The first UI component does null checking in its validation and maps its I1 view model into I2 for processing. The second UI component directly passes its view model to the processing service.

Here we have code duplication in the UI component, but we don't do unnecessary work in case of updates. Since I1 and I2 are unrelated, we have to maintain them in parallel.

2. Share UI and lose nullability information
   The create view model service creates an I1 for both new and existing entities. We always validate for null and always map the I1 view model to I2.

Here we have no code duplication, but we do unnecessary work in case of updates. We also need to add tests to verify that the view model service actually sets all the propeties to a value in case of an update. Since the properties are no longer not-null, we lose the guarantee that the properties actually have a value.

Since I1 and I2 are unrelated, we have to maintain them in parallel.

3. Share UI and use hiding pattern,
   The create view model service creates an I1 for new entities and an I2 for existing entities. We define I2 to be a subtype of I1 and instantiate the UI with I1. Upon validation we pattern match over the view model and pass it directly to the processing service if the view model is an instance of I2, and we do a null check and map to I2 if it isn't.

Here we have no code duplication and we also don't do unnecessary work. Since I2 is derived from I1, it doesn't have to repeat the properties they have in common, but it has to use the "new" key word for those properties that we want not to be nullable. We can reduce the repetition of code in the view models at the expense of the mental overhead of using the "new" keyword.

We also have to add a pattern match in the validation UI component to make the distinction between an I1 view model that requires validation and mapping and an I2 that can be passed to the processing service as is.

---

These are the trade offs that I can see for the various options. Whether code duplication, doing unnecessary work or using an unusual pattern is a good idea is in itself an interesting question.

[iam3yal]

What are the criteria for a good idea?

Simplicity.

If you can't explain the problem independently to how your system works and can't explain your idea in few sentences then I'd say your attempted solution is not sound, e.g. The problem: The amount of manpower that needs to be recruited to control traffic is extremely high and probably not feasible but not only for this reason. The solution: A traffic light system that automatically controls the traffic. this is just a glimpse of the thought process.

Many times people would focus on how they want to solve the problem rather than elaborating on the actual problem that leads to discuss irrelevant things, confusion and going in circles to the point of being counterproductive.

Now, when people here are telling you they that don't recommend your approach and try to explain to you the reason but you're taking it person or getting offended then there's no point discussing anything.

Every engineering solution has trade offs and so do the options we have in this use case

Yes but fortunately that's not how engineering works, you don't start with solutions and say this is my problem I have with them... you start with the problem and explore potential solutions that may or might not have tradeoffs.

[NielsHoogeveen]

I am aware I should not have started my question with the opening sentence, and I shouldn't have closed it the way I did. That provided too much context and lead away from the question at hand. I should just have asked whether the behavior in the code fragment I sent worked as intended. That would have saved us a lot of unnecessary discussion. I apologize.