Question Deriving from a sealed class : Getting around the restriction ??

RogerInHawaii

New member
Joined
Aug 29, 2021
Messages
1
Programming Experience
10+
I want to have a function that takes an argument that is specifically a MassInGrams value and maybe even returns a MassInGrams value. Something like:
C#:
public MassInGrams MyMassManipulationFunction( MassInGrams theMassOfTheObject)
{
    // ...
}
HOWEVER, that MassInGrams object should simply BE a float value, nothing more, nothing less.

I would hope that all I had to do was something like derive a MassInGrams class from a float, like:
C#:
class MassInGrams : float
{
}
But C# doesn't like that because float is a sealed type, you can't derive classes from sealed classes.

So how do I do what I want to do, which is to assure that the only values that are passed in to my function are MassInGrams type values and the only type of variables that can receive the return value from the function are also MassInGrams variables, and not simply any old type float value or float variable?

I encounter this type of issue over and over again, and I see functions defined by others that specify function arguments and return values that are simply floats or doubles or ints when in fact they represent specific characteristics, like the mass or velocity of an object. The only thing I've ever seen is that they just NAME the float variable accordingly, so you have something like:
C#:
float theMass;
or for a function:
C#:
public float MyMassManipulationFunction( float theMassOfTheObject )
but that in no way GUARANTEES that the value that's passed in is actually a MASS type value. You could just as easily do the following:
C#:
float theNumberOfPeopleInTheBoat = 10;
and then call :
C#:
MyMassManipulationFunction( theNumberOfPeopleInTheBoat );
which would make no sense but be perfectly compilable.

So how do I do what I want to do so that the programmer is required to pass in the right kind of values?
 
Last edited by a moderator:
You can't inherit a sealed class but it wouldn't matter even if you could, because float isn't one. float is a C# alias for the System.Single type, which is a structure. Structures cannot be inherited.

You're trying to solve a problem that no one has. People use numeric data types all the time and no one thinks "gee, I wish I had loads of different aliases for those numeric data types for all the different things that can have numeric values so I could use a different type everywhere I need a number". That would be terrible. You name your variables and properties descriptively and then it's clear whether you're using the right value or not. If you think that you need a different type for everything that a number might represent then why stop there? Why not inherit string and have different types for a person's given name, their family name, their email address, their physical address, etc, etc, etc? Why not have a different type of TextBox depending on what the data in it represents? The idea is nonsensical, if you take it to its logical end. People have been programming for decades - over two decades myself - and numeric types distinguished by the characteristics of the numbers, rather than what they represent, has not been an issue so far. It won't be for you either, as long as you name everything sensibly.

If you're still determined to use dedicated types then you will have to use composition rather than inheritance, i.e. you can define your own class or, more likely, structure named `MassInGrams` that has a property of type float. Of course, you'll then need to do some extra work to make sure no one puts a number in there that actually represents a height in centimetres.
 
Why not inherit string and have different types for a person's given name, their family name, their email address, their physical address, etc, etc, etc?
Funny that you mentioned this. As I recall, some of the object oriented software design books in the 90's did this. I'd like to say it was even someone as famous as Rumbaugh did this in his earlier works, but I don't own any of those books because I despised his approach then, and as you said, we modern programmers have figured out that we don't really need it.

To play devil's advocate though, there are some types for which one would like to have tighter control over. It's not necessarily to confirm that the correct type is being passed in, but rather to enforce validation rules. For example, it doesn't really make sense to have negative mass, nor does it make sense for probability values to go below 0.00 or above 1.00. It would be nice to have the validation performed by the "data type" rather than than the method receiving the value.

And also to further play devil's advocate, then I guess modern programming languages should depricate all enum types. Let the caller just define constant integer values of the appropriate type or directly pass in constant values that may or may not be appropriate.
 
Last edited:
it doesn't really make sense to have negative mass
True. We do have unsigned numeric types but they so rarely get used because the data is so often already in a signed type or needs to interact with other signed values that it's not worth the effort.
 
Back
Top Bottom