Multiple Classes, same name
-
I have read you contribution. Thanks for that. What I want doesn't exist and I'm not interested in alternatives that already exists. I want something new. I want the team that creates C# to make that happen. All of you think I have a dumb idea. But for me, inheritances is dumb. Interfaces are dumb, and many more Why? You don't need them. There are other ways to do the same. But they exist because someone had the idea and others liked it. The difference is, they understand it. Nobody understands my idea. Doesn't matter, I'm used to it. ps: I don't want a class with two representation of the skill data. I just do not want that. (of course it's an idea that crossed my mind)
Wiep Corbier wrote:
ps: I don't want a class with two representation of the skill data. I just do not want that.
But I suggest a single reperesentation! Two representations would be really bad design. Two different presentations is a completely different thing. It is like when your code handles a binary integer, you don't present it like a binary integer but format it into a character string. You may format it as hex, octal, decimal, with or without leading zeroes, trailing currency sign or whatever. For binary reals you print out the number of decimal positions according to need. The internal integer or real binary value is unique and unaffected by the presentation format. Similar with you skills list. Whether it is stored as a single string with | separators, a list, a dictionary or as a database table doesn't matter: From that unique representation you may format it as a string, as a list or in any other format. For console output, you use different Format or ToString format strings, for binary formats, you use different accessors (that may also use Format/ToString when appropriate). An accessor isn't a representation. It is an accessor, a way to get at a representation. The representation is independent of it.
-
The list are not bigger than 80 items. My solution is already super fast. That's not the problem. btw: I'm aware of dictonary.
-
Wiep Corbier wrote:
My solution is already super fast.
So don't worry about the expense of searching an 80 item list. Even though a straight search in a simple string is super fast, it does not imply that other alternatives are unacceptably slow.
I agree :) Everywhere else I use a different approach like list, dictonary etc I use ms sql server databases. I love creating related tables. It's what I do all the time. But this time only I took a different path. (
-
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?
Whose "popup"? You'll need a separate NAMESPACE for each DUPLICATE CLASS NAME. Then you can "code logic" for YOUR "popup" or whatever. And in your CODE, you qualify with a NAMESPACE that VS can resolve with (Intellisense-wise). There is no other magic; it's all in the head. YOU are the only "customer" at this stage. Beyond that, you use "Interfaces".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
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:
So, when I instantiate a new CandidateFunction, I want a popup asking me which one I want to use.
Making 2 classes indistinguishable is a bad idea to the core. In 35 years, I never came to a case that need such Gremlin.
Patrice “Everything should be made as simple as possible, but no simpler.” Albert Einstein
-
Thanks, this looks like a good idea. Don't remember why I dismissed it years ago, because this is the way I do this normally. I'll get back on it.
I've thought about it, and it's time to switch to subtables. I started that now. Thanks for the anwers all participants.
-
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?
Well that was an interesting discussion which seems to have shown that you need to redesign your data structure to meet your requirements. The entire issue revolves around the string of skills which you are storing incorrectly (as a number of respondents have pointed out). This should be seen as a valuable lesson (hopefully others will also benefit). Do not be discouraged by any negative responses, this was a good discussion with some interesting information generated.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
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?
For me personally, I would say that you should be trying to solve a modelling issue rather than fix it with a "change to the complier" Which I wouldn't agree to it, if I worked for Microsoft
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
I have read you contribution. Thanks for that. What I want doesn't exist and I'm not interested in alternatives that already exists. I want something new. I want the team that creates C# to make that happen. All of you think I have a dumb idea. But for me, inheritances is dumb. Interfaces are dumb, and many more Why? You don't need them. There are other ways to do the same. But they exist because someone had the idea and others liked it. The difference is, they understand it. Nobody understands my idea. Doesn't matter, I'm used to it. ps: I don't want a class with two representation of the skill data. I just do not want that. (of course it's an idea that crossed my mind)
Perhaps I misunderstand something ... but when I read your question I want to ask why you don't create a Property (as a List of String or as List of Class-Object) which could be used in the way you want : either you use only a part of the Property (in case of List of String) or you use a sub-Property (in case of List of Class-Object).
-
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?
You can't have multiple classes with the same name, unless they're in different name spaces. This won't work:
namespace One
{
public class ABC {}
public class ABC {}
}but this will (as long as you fully qualify all instantiations):
namespace One
{
public class ABC {}
}namespace Two
{
public class ABC {}
}You could use inheritance, but your class names would still have to be unique.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I have read you contribution. Thanks for that. What I want doesn't exist and I'm not interested in alternatives that already exists. I want something new. I want the team that creates C# to make that happen. All of you think I have a dumb idea. But for me, inheritances is dumb. Interfaces are dumb, and many more Why? You don't need them. There are other ways to do the same. But they exist because someone had the idea and others liked it. The difference is, they understand it. Nobody understands my idea. Doesn't matter, I'm used to it. ps: I don't want a class with two representation of the skill data. I just do not want that. (of course it's an idea that crossed my mind)
Wiep Corbier wrote:
What I want doesn't exist and I'm not interested in alternatives that already exists. I want something new.
Good luck with that Sparky... I've been coding for over 40 years, and have NEVER come up with a use case for identical class names (I'd really like to see multiple inheritance come back, though). Your actual problem is your weak design, not a perceived missing feature in C#. Fix your code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
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 :)
Wiep Corbier wrote:
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 think he got it at the very beginning. But at which point do you want the intelli pop up to come? At compiling time... ok, do you know with of the functions is needed in each 62 places where the name is used? Maybe you do now... but then you go to another project and then you have to make some additions 3 or 4 years later... or you leave and another guy gets in your project... or the project is so big that there are several people working on the same area at the same time... good luck when compiling (and don't forget to start one hour before the test because you will need some time to click all popups). At execution time... how will the user know, which class is the one needed? Ok, maybe your user knows it, but how will my user know it? Or the new customer's employee. What are the consequences of a bad selection? Good if I see I have selected the wrong option soon enough, but what if they don't realize it? Are the differences between the classes compatible? Will you need plausibility checks? How can you choose which plausibility check is needed each time? it is already difficult enough to get the exact result you (and they) want as it is, if you add ambiguity on top... I don't even want to imagine it.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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.
No, because the surname (namespaces) differentiates them.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Richard MacCutchan wrote:
Well they have to teach tell them something in school.
Teaching is slowly disappearing, specially quality teaching :sigh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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?
Pardon me if this was already mentioned, this is a fairly long thread. But I have a feeling that this case is handled by namespaces for a couple of decades. I mean you can have a POCO for your needs in one namespace and another class for what customers want in the other namespace. And you can map one to another manually or via some tool like Automapper.
Quote:
I want a popup asking me which one I want to use.
Also, I have a feeling that you're confusing language and tooling. Is popup some sort of language construct or a feature in IDE? Which one? VS? VS code? Jetbrains rider?
-
You can't have multiple classes with the same name, unless they're in different name spaces. This won't work:
namespace One
{
public class ABC {}
public class ABC {}
}but this will (as long as you fully qualify all instantiations):
namespace One
{
public class ABC {}
}namespace Two
{
public class ABC {}
}You could use inheritance, but your class names would still have to be unique.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I'm sorry I've missed this answer and discovered it only when posted mine with the similar thinking
