|
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.
|
|
|
|
|
Ten years from now, kids will honestly believe that Elon Musk invented the electric car, and all later (and earlier) electric cars are derived from the Tesla series.
|
|
|
|
|
Well they have to teach them something in school.
|
|
|
|
|
Richard MacCutchan wrote: Well they have to teach tell them something in school.
Teaching is slowly disappearing, specially quality teaching 
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.
|
|
|
|
|
Invalid comparison. That's not even close to what your original post is about.
You're thinking of the problem you posted about in terms of people, not in terms of a computer. When building your car, which engine is the car supposed to get, gas, diesel, or electric, if they are a class called Engine? How is the computer supposed to know?
Change your mindset.
|
|
|
|
|
Asking questions is a skill
I will never ask a question on this platform again.
Thanks for your reply. Have a nice day.
|
|
|
|
|
Why is asking questions a skill? Because you have to think about your question before you ask it. Think about the context your question falls in.
All you said was "I want this, and it's up to the experts to solve it". Well, the experts just told you your idea isn't workable at all and you just stomped off.
But, actually, the idea is kind of workable, but it would involve converting C# to an interpreted language instead of compiled. It would also involve rewriting the type resolver to examine the code ahead to attempt to find the "best fit" at runtime based on insufficient information. This wouldn't even work in all cases as there isn't enough information at runtime to even "new up" an instance you haven't used yet.
This would also have the effect of destroying the performance of the language because of all of the overhead of trying to guess at which type you were talking about!
|
|
|
|
|
Wiep Corbier wrote: I will never ask a question on this platform again.
That's not the right approach.
My observation is that you had a clever idea and wanted to share. That's great and awesome and thank you for doing that. I think where this went south is that you wanted everyone else to think it was clever and no one else has. That's fine. Don't take it personal. If you think it's a great idea pursue it and prove everyone wrong. Don't run away just because no one agreed with you.
Don't take these posts personal. No one is attacking you, they were just attacking the idea. But keep having ideas. That's how innovation happens.
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.
|
|
|
|
|
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> 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<string> 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 apply at each point in the chain. This is not a useful feature, and it's certainly not one you could test.
If you don't believe us, please raise it as a feature request against C# (the language is open source after all). Perhaps you'll believe them.
|
|
|
|
|
Hi 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.
|
|
|
|
|
Wiep Corbier wrote: I store Skills as a string in the database.
They are stored like this: Skill 1|Skill 2|Skill 3|Skill 4
And that all on it's own is a poor idea. Do you realise how much work it is in SQL to change a skill when you store it like that? First off, it wastes space, secondly it's prone to user error and two skills that are described differently but are actually the same, and thirdly because it's hard to work with for anything more complex than INSERT and DELETE operations.
For example, suppose HR realises a mistake has been made: EmployeeX doesn't have any knowledge in "Skill 2", it's "Skill 5" he knows. Now write the SQL to fix that ... and bear in mind that you might have "Skill 2", and "Skill 21", "Skill 22", "Skill 23", ... so you can't rely on string replace functions or you will cause further errors.
Oh, and while you are at it, fix the spelling mistake that Deirdre always makes in "Skill 17" but no one else does.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'm a senior. This is not a problem for me. It works 100% perfect.
I have solved this years ago. Trust me.
Anyway, back to the topic please. But you already gave me an answer. Thanks. 
|
|
|
|
|
Then I feel sorry for the company that employs you - that is a rookie mistake, and generally means the rest of the DB design is as full of errors ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Wiep Corbier wrote: 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
Actually, that's what indexes on a database table are for. If you had a Skills table it would not have to do a table scan to find the specific skill you wanted. And it would actually be much much faster than checking all the strings to see if it contains.
You would use foreign keys and it would be magnitudes faster than doing a LIKE statement.
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.
|
|
|
|
|
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.
|
|
|
|
|
Want to bet he doesn't redesign? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
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: 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. (
|
|
|
|
|
Dave 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!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
