Multiple Classes, same name
-
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, 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.
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.Bazclass, or thatFooBar.Bazclass, 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 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.
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 wrote:
Will this ever happen and if not, why not?
I hope not. There is enough confusion in programming languages without adding to it.
What this, another Richard? :)
-
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
-
What this, another Richard? :)
-
Yes, but if you check my full name you will find I am different from the other one (he knows much more than me).
So, it is possible to have more than one Richard. :cool: Maybe this could be true for Classes. Not yet, in the future. :java:
-
So, it is possible to have more than one Richard. :cool: Maybe this could be true for Classes. Not yet, in the future. :java:
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 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.
Like electric cars, dumb idea, petrol heads said. Because, they don't know better.
-
Like electric cars, dumb idea, petrol heads said. Because, they don't know better.
-
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?
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.IsNullOrWhiteSpacecheck? 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 -
That is true. It has to do with the fact you call it dumb. That isn't very constructive. But don't waste your time on me.
-
That is true. It has to do with the fact you call it dumb. That isn't very constructive. But don't waste your time on me.
Sometimes, the most constructive thing you can be told is "that is a dumb idea - don't waste any more of your time on it". And one of the hardest things we have to do as developers is recognise that fact about our own stuff and throw it away and start again. We all do it: I had a brilliant scheme laid out - pages and page of design documents, using
abstractclasses to their full extent: everything was beautiful, it would be perfect. Except ... C# doesn't haveabstract static methods. And for very, very good reasons. So the whole lot: design, code, the whole idea was a pile of garbage, and I had to chuck it and start again. That really is hard to do, but it's part of the job. Yes, I could have bodged round the problem, hacked it here, forced it there - but the result would be clumsy, hard to work with, and difficult to maintain; as well as having a lot of "holes" for bugs to hide. Trust us: this is an idea you should drop!"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
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.IsNullOrWhiteSpacecheck? 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 applHi Pete, All these problems are already solved by me. Again. I store Skills as a string in the database. They are stored like this: Skill 1|Skill 2|Skill 3|Skill 4 of course the data is different but I show you the idea Then, customers (being developers) asked me if i couldn't provide a class with data stored in Skills as a list A list Skills has "items"
public class Skill { public string Item { get; set; } }It doesn't matter if there is data in it, I handle that. So, I said to my customers I could do what the want but they need to address another Class:
CandidateFunctionWithSkillsList
No problem. But it made me think: what if my customers could make a choise how to recieve the data using the same name for the claas but had the option how it was presented/formatted. It is just something I would like. So I went on searching and discovered there were alternatives. But not exactly what I want. It doesn't exist. So, my question to the C# team is: can you make it happen in a next release.
-
Sometimes, the most constructive thing you can be told is "that is a dumb idea - don't waste any more of your time on it". And one of the hardest things we have to do as developers is recognise that fact about our own stuff and throw it away and start again. We all do it: I had a brilliant scheme laid out - pages and page of design documents, using
abstractclasses to their full extent: everything was beautiful, it would be perfect. Except ... C# doesn't haveabstract static methods. And for very, very good reasons. So the whole lot: design, code, the whole idea was a pile of garbage, and I had to chuck it and start again. That really is hard to do, but it's part of the job. Yes, I could have bodged round the problem, hacked it here, forced it there - but the result would be clumsy, hard to work with, and difficult to maintain; as well as having a lot of "holes" for bugs to hide. Trust us: this is an idea you should drop!"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
That is what car makers told Elon Musk. Trust us, your idea is never going to work. They said: Where do you get electricity? How do you store your energy source? What will be the range? Etc. No, the big shots told him: it will not work. Tesla is today the biggest car builder. If you think in unpossibilities you will never innovate.
-
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.
Wiep Corbier wrote:
It is a nice to have for me and probably someone else.
Not really. Even if the feature were there, when you went back a day later and looked at your code you'd have no idea which class the code was referring to.
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
That is true. It has to do with the fact you call it dumb. That isn't very constructive. But don't waste your time on me.
Wiep Corbier wrote:
It has to do with the fact you call it dumb.
I don't call it dumb, it is dumb. And the argument re petrol or electric cars is not even remotely connected. Electric cars are all easily identified as different from their petrol counterparts.
Wiep Corbier wrote:
don't waste your time on me.
At last a sensible suggestion.
-
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
varwhen 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
Richard Deeming wrote:
There has to be some way to disambiguate the two people.
I think the OP is asking for the computer to do that. In other words I write SomeClass temp = new SomeClass(); and up pops some intellisense so that I can pick SomeClass from file1 or SomeClass from file2. Internally, C# would clearly have to track which one it is. Which makes this idea even worse because if you come back the next day to read your code you won't know which one it actually refers to. It could be done, and probably not too hard with some sort of internal tracker in VS but a terrible idea regardless. :-D
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
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?
Wiep Corbier wrote:
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.
Forget multiple classes with the same name, I'm wondering why in the world you would do this.
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
Wiep Corbier wrote:
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.
Forget multiple classes with the same name, I'm wondering why in the world you would do this.
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
Why? I just explained it several times.
Quote:
When answering a question please; Read the question carefully
