Multiple Classes, same name

Wiep Corbier

For the next C# version I would like the ability to have multiple classes with the same name. But, this is for POCO's What do I mean? I have an poco with the name CandidateFunction

public class CandidateFunction
{
    public int CandidateFunctionId { get; set; }
    public int CandidateId { get; set; }
    public int FunctionId { get; set; }
    public string Skills { get; set; }
    public DateTime Date { get; set; }
}

As you can see, the property with the name Skills is a string. It can be a long string and it stores one or more Skills. But customers want to see Skills as a list so I have another POCO

public class CandidateFunctionWithSkillsList
{
    public int CandidateFunctionId { get; set; }
    public int CandidateId { get; set; }
    public int FunctionId { get; set; }
    public List Skills { get; set; }
    public DateTime Date { get; set; }
}

It has another name. Now, I want both POCO's with the same name. I know there alternatives for what I want but I don't like them. So, when I instantiate a new CandidateFunction, I want a popup asking me which one I want to use. Will this ever happen and if not, why not?

Richard Deeming

Wiep Corbier wrote:

Will this ever happen and if not, why not?

No, because you create a instances of your class at run-time, and you don't want the user to be presented with a pop-up when your application is running asking them to pick which class to instantiate. You can already have different classes with the same name if they're in different namespaces. You can have different classes with the same name and namespace if they're in different assemblies, with no reference between the two. But they're an absolute pain to use. You have to create an "external alias" for each reference in order to disambiguate them. Computers aren't magic. They can't "guess" which class you meant to use. And if two classes have the same name in the same namespace, with no "external alias" to disambiguate them, then there is no way for the computer to uniquely represent the class you want to use.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

OriginalGriff

No. Because - frankly - it's a dumb idea. Selecting class types at run time based on what the user decides is a recipe for convoluted, messy code that doesn;t work well in practice because users are not developers. That means that have no idea what a class is, or why they want to select one. If you want users to decide what to create, ask them "Do you want a Candidate, or a Candidate with skills?" and explain what the difference is in their terms and what effect the decision will have. You cannot "leave that to the system" and get them to choose based on two similar names.

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!

Wiep Corbier

Quote:

Computers aren't magic. They can't "guess" which class you meant to use.

But anything else computers can guess? It's not up to me to solve this problem. That's up to the people that invent new possibilities for c#. I think it can happen but no one has ever ask this option. So, get things done, make it happen. :)

Richard Deeming

But that's the point - it's not a problem. Nobody is seriously asking for the ability to have multiple classes with the same name in the same namespace in the same assembly. It just makes no sense. Imagine everyone in your office was called Wiep. If you put a message up on the wall saying "Wiep, call me urgently! - Wiep", would anyone have the first clue who was supposed to call whom? It would just be utter chaos. You'd have to find some way to disambiguate your names in order to work.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Wiep Corbier

The point is Richard, I understand the problems. But imagine this. You work in a office room with a colleguea also called Richard. A person walkes in and asks for Richard. People will ask, which Richard? (popup intelli) Got it? I know it doesn't work yet, and I know why. I just want it to work in the future. ps. C# (8?) now has the ability to work around null values in classes. Who asked for that? I didn't. Who cares? No one. But it's there anyway. Just....progress :)

Richard Deeming

Wiep Corbier wrote:

People will ask, which Richard?

There has to be some way to disambiguate the two people. Usually you would use the surname. It's no different with classes. If you have two classes with the same name, then they have to be in different namespaces so that you can disambiguate them. Otherwise, even if you could come up with an intellisense popup to let you pick a class - which could be difficult if the only difference is one character on line 42! - there would be no way to represent that choice in the compiled program. And before you suggest that the compiler could generate some form of "mangled" name to uniquely identify the class, remember that you'd also have to represent that choice in the source code. And the source code is meant to be read by humans. There are enough arguments against using var when the type isn't clear, without making an explicit variable type ambiguous as well!

Wiep Corbier wrote:

C# (8?) now has the ability to work around null values in classes. Who asked for that? I didn't. Who cares? No one.

Lots of people asked for it, and lots of people care. You can probably find the history in the C# Language Design repository: GitHub - dotnet/csharplang: The official repo for the design of the C# programming language[^]

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

kalberts

Richard Deeming wrote:

There has to be some way to disambiguate the two people. Usually you would use the surname.

Doesn't always work. In my family history, there is a case of three boys, born of the same parents, two of them in the same year, all with the same name. The first one was born shortly after New Year, but lived for only a few days - long enough to be baptized. The second one was born in December the same year, and lived for about a year. The third one, born a couple of years later, grew up to an adult. When I looked up the name of their paternal grandfather, I was not very surprised: The three boys were named after him. In those days, having a heir to carry your name on, one who grew up to carry the lineage on, was essential. But I digress.

Wiep Corbier

Richard, I know that what I want isn't possible. That's the reason why I post this. It is a nice to have for me and probably someone else. But what about something else like it: inheritance. Why? Are people to lazy to copy properties? inheritance is not a must. It is a nice to have. btw: I did predict you would mention the surname Richard? Which Richard? Richard String or Richard List? ps: just for fun.

Lost User

Wiep Corbier wrote:

Will this ever happen and if not, why not?

I hope not. There is enough confusion in programming languages without adding to it.

Richard Deeming

Inheritance is a useful tool for encapsulating state and/or behaviour. It can be overused, but at the moment in C# it doesn't introduce any contradictions or ambiguity. C# doesn't have multiple inheritance, so it doesn't suffer from the "diamond problem"[^]. I'm still struggling to see what problem you think your idea would solve. All I can see is code where I can't tell whether you meant this FooBar.Baz class, or that FooBar.Baz class, because they both have identical names.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Richard Deeming

It would still be very confusing if they had all made it to a family gathering. You'd have to resort to pointing at the person you meant. :)

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Wiep Corbier

What this, another Richard? :)

kalberts

For two of them it would be pointing towards the graveyard. They never lived at the same time.

Lost User

Yes, but if you check my full name you will find I am different from the other one (he knows much more than me).

Wiep Corbier

So, it is possible to have more than one Richard. :cool: Maybe this could be true for Classes. Not yet, in the future. :java:

Lost User

Wiep Corbier wrote:

So, it is possible to have more than one Richard.

Yes, but you can tell which is which by our full names.

Wiep Corbier wrote:

Maybe this could be true for Classes. Not yet, in the future

Not ever; as mentioned more than once, it's a dumb idea.

Wiep Corbier

Like electric cars, dumb idea, petrol heads said. Because, they don't know better.

Lost User

Which has absolutely nothing to do with your question.

Pete OHanlon

I'm going to start by pointing out the most obvious thing. Your two POCO's have different implementations. Bear with me, because this is important for the rest of the discussion. As these two POCO's have different properties, you have an immediate issue which is, what happens when you want to consume your code? You have Skills as a string in one, and a List of strings in the other. The code that calls this is going to have to conditionally choose the operations to perform on the Skills based on the "popup". Now, you might have additional operations that chain off those operations, so you might have a POCO Skill class that looks like this:

public class Skill
{
public int SkillId { get; set; }
public string SkillRange { get; set; }
}

and another one that looks like this:

public class Skill
{
public int SkillId { get; set; }
public List SkillRange { get; set; }
}

And maybe you have another class that looks like this

public class Skill
{
public Guid SkillId { get; set; }
public string SkillRange { get; set; }
}

For good measure, our codebase has this one thrown in

public class Skill
{
public Guid SkillId { get; set; }
public List SkillRange { get; set; }
}

We are creating a real mess of code here that we are expecting someone to be able to grok easily. The more we add to the code base, the harder it will be to keep these in line, and we have violated clear code principles. Why have we violated this? Suppose we have some consuming code that looks like this:

Skill skill = GetPopulatedSkill();
var id = skill.SkillId;
ValidateSkillRange(skill.SkillRange);

What validation are you expecting ValidateSkillRange to be doing? Is it a string.IsNullOrWhiteSpace check? Perhaps you just want to ensure it's not an empty list. Perhaps you need to iterate over items in the list and check certain values in there. The problem is, unless you start covering all of the different combinations of cases, the compiler isn't going to have the last scooby of a clue how to fix this, even if the user, by luck, picks the correct one. Bear in mind that you may have different parts of your code needing different Skill implementations at different points; you're expecting the user to be able to guess which one needs to appl