Multiple Classes, same name
-
Just because "it's worked for years", doesn't mean it was designed properly. The list of skills NEVER should have been a string holding multiple values like that. It should have been a separate table with foreign keys back to the people that have those skills. The skill is stored ONCE and can be used multiple times. This saves space in the database. It's not the language that needs to updated to support your poor skills. It's your skills that need to be updated to better support your customers.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakDave Kreskowiak wrote:
It's not the language that needs to updated to support your poor skills. It's your skills that need to be updated to better support your customers.
Hear hear! :applause:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
The list of skills NEVER should have been a string holding multiple values like that. It should have been a separate table with foreign keys That was my original idea too. Very logical. I would do it also, even as a habit BUT By exeption I will explain: Take a skills list with 1000 skills. Put them in a list. Now find and skill item with the value "Skill 1" Maybe, this skill is on position 998 Do a find: it will seach at least 998 items in a list before that skill is found Do a contains on a string and there is one search. If(Skill.Contains("|Skill 1|")) than, a Yes or a No. True or False. If I'm wrong, I will redesign.
If my skill is "baking breads|cakes" it won't work as you expect it to. If you frequently will search lists of 1000 skills, you should rather put them in a dictionary (i.e. hash table). That would work even with "baking breads|cakes". Another side is that if you measure the time to search a 1000 element list, you'd probably be surprised by how fast it is. If the search is initated due to a user interaction, all the other stuff involved will require magnitudes more resources. Worry about the time for searching an in-memory list only if it is done thousands or tens of thousands times for each user interaction.
-
If my skill is "baking breads|cakes" it won't work as you expect it to. If you frequently will search lists of 1000 skills, you should rather put them in a dictionary (i.e. hash table). That would work even with "baking breads|cakes". Another side is that if you measure the time to search a 1000 element list, you'd probably be surprised by how fast it is. If the search is initated due to a user interaction, all the other stuff involved will require magnitudes more resources. Worry about the time for searching an in-memory list only if it is done thousands or tens of thousands times for each user interaction.
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:
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.
So why don't you provide that in the one class you've got? dotNet doesn't know how to ask the customer - their language, preferred terminology, CLI or GUI, how your GUI is laid out and how the selection list should be presented. You do. You are the only one who can ask the customer in a proper way, and from the selected alternative initialized the object this way or that way. Or if you insist, create an object of this or that class. Two accessor methods of a given class may very well reference the same private data, presenting it in different formats (or set functions parsing value in different ways before storing it in the private value). You would have an explicitly declared internal value, not implicitly declared ones, so the simple {get; set;} would be relpaced with e.g. for the list format:
{ get { return skills.Split('|'); }
set { skills = string.Join("|", value); }}In this case, "skills" may actually be the implicitly declared variable from your string based accessor. Your (single) class may have as many different accessors (here: presentation formats) as you like. Of course you may have have initializers as well accepting intial values in either format, but being parsed and stored in one common format. If you are using this "skills" case as a simple way of illustrating what you think should be a commonly available mechanism for a lot of different purposes, then you should come up with a better illustration of the need. If your real problem is accessing the list of skills as a list or as a string, then it is handled by two properties (accessors) presenting the skills in two different ways from the one class. If you insist on two different classes with a single name, they will be different (you asked for it, you got it) - different set of members, different methods, different semantics. In the general case, only the name would be the same. You may construct examples where two different classes happen to have some members with similar names and somewhat similar semantics, while others differ. The overlap is more or less "accidental"; a general mechanism could not require "> x% similarity between same-name classes", it would be general (sic!). We have a general object class - it is called "object". Your proposal is, in the generaliz
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)
-
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
