|
OK, my point was not to illustrate how to insert an element into a list, but to illustrate a mechanism.
I just picked a very simple example 'off the top of my head' to show different exit handling - and as you point out: For that specific very simple example, there may be simpler ways to do it.
I could easily make a complex 50-line example to show the same mechanism in a composite context, but as a first presentation of the idea, it would clutter up the presentation. So I chose something simpler.
There certainly are cases where you have different exit handlers that can not be replaced by a predefined list method.
|
|
|
|
|
Member 7989122 wrote: OK, my point was not to illustrate how to insert an element into a list, but to illustrate a mechanism.
Ah, sorry. Sometimes I'm too literal.
Marc
|
|
|
|
|
I'll preface this by saying if you really want that syntax today, you could write that part of your program in Nemerle and use its macros to transform the syntax tree to your heart's content. I think that would let you create the kind of loop you're looking for. So you could write the class that performs the looping in Nemerle and just call it from C#/
To answer your question:
One disadvantage that comes to mind is that the change would encourage the use of loops where they're unnecessary, and would also encourage the use of the wrong data structure to solve a given problem. I think that loops with multiple break/exit conditions are usually an antipattern; if a coworker has to modify it (or you have to come back and modify it after 6+ months), the reasons for the conditional exits aren't always clear.
In the example you gave, the loop goes through the entire list every time you want to bump a reference count. If the list is relatively small, it's not a huge problem. If the list becomes large, then the O(n) lookup every time is going to hurt.
Instead, you could do something like:
public class ElementReferenceCounter
{
private readonly Dictionary<string, ListElt> elements;
public Elements()
{
elements = new Dictionary<string, ListElt>();
}
public void AddOrIncrementRefCount(string refKey)
{
if (elements.ContainsKey(refKey))
{
elements[refKey].RefCount++;
}
else
{
elements[refKey] = new ListElt(refKey, 0);
}
}
public void DecrementRefCount(string refKey)
{
if (!elements.ContainsKey(refKey)) return;
if(elements[refKey].RefCount == 1)
{
elements.Remove(refKey);
}
else
{
elements[refKey].RefCount--;
}
}
}
And you get O(1) list element lookup, at the expense of slightly higher memory use. More importantly, the interface is easy to understand. Anyone who works on the code in the future will see a call like
myList.AddOrIncrementRefCount(refkey) and immediately know the code's intent. It's easier to write tests for it this way, too.
In the future, if you found that you need to have your reference counter backed by a HashSet or a List instead of a Dictionary, go ahead and change it. As long as the class interface and behaviour stays the same, any code that uses it will just work without any changes.
I realize all that code is really specific to your example, and what you're proposing would be usable in a much wider variety of scenarios. It just seems that in most of those scenarios, there are probably more testable and maintainable ways to solve the problem.
In summation: what you propose isn't crazy and wouldn't cause major problems for the language, but it would encourage hard to maintain code. That by itself doesn't make this a bad idea...but you did ask for disadvantages, and that's one that came to mind.
|
|
|
|
|
It is relatively easy in C# to write a method, or an Extension Method, that will return whatever data, as well as some indicator (nullable bool, or enum), that contains all the possible conditions you describe: match, no match, error.
You'll find an example of that in a recent QA answer of mine: [^] .
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
I disagree with "two alternate loop 'tails' ... another if the loop was left prematurely" -- that can be handled at the test site.
Almost like giving a while an else .
Just for fun, I altered a simple while loop into the following attrocity:
while ( true ) if ( ( ch = sr.Read() ) != -1 )
{
System.Console.WriteLine ( "{0} {1} {2}" , i , ch , (char) ch ) ;
if ( ch == 26 )
{
System.Console.WriteLine ( "Found a char 26 at offset {0}" , i ) ;
break ;
}
i++ ;
}
else
{
System.Console.WriteLine ( "Reached the EOF" ) ;
break ;
}
Just be sure to break out of the else .
Now to attempt:
# define whilst(x) while ( true ) if ( x )
Edit:
# define whilst(x,y) while ( x ) if ( y )
...
int ch ;
int i = 0 ;
whilst ( sr.BaseStream.CanRead , ( ch = sr.Read() ) != -1 )
{
System.Console.WriteLine ( "{0} {1} {2}" , i , ch , (char) ch ) ;
if ( ch == 26 )
{
System.Console.WriteLine ( "Found a char 26 at offset {0}" , i ) ;
sr.BaseStream.Close() ;
}
i++ ;
}
else
{
System.Console.WriteLine ( "Reached the EOF" ) ;
sr.BaseStream.Close() ;
}
modified 28-Sep-16 17:43pm.
|
|
|
|
|
Dictionary ... TryGetValue ?
Reinventing: it's yet another way to get a head
|
|
|
|
|
I don't see how that could provide a programming mechanism for specifying different handling of a loop run to its end vs. premature exit from the loop.
You might of course argue that thanks to the dictionary class, you will never have have a need for handling premature loop exit differently from loop completion, that it always can be handled by a dictionary instance. I must admit that I do not immediately see how.
|
|
|
|
|
Hi All,
Had a bit of an odd thought, some here might be able to shed more light on... I am starting to wonder if the interview process is more to do with 'can we work with this guy' more than 'this guy has X years of Y'. This is based on the fact that tech based skills change so often it can be nearly impossible for anyone to stay at the bleeding edge. Am I right...
|
|
|
|
|
You are probably right - we definitely do interview on the basis of "how do you work when there are things you don't know" rather than "what things do you know" as both IT and our vertical business change so very rapidly.
(In that context a GitHub or a Codeproject article etc. is more useful to us than a CV)
|
|
|
|
|
I must say a couple of places I interviewed at did have a print out of my CP article...
|
|
|
|
|
glennPattonInThePUB wrote: I must say a couple of places I interviewed at did have a print out of my CP article...
Was is placed under a big banner that said "don't be this guy"?
|
|
|
|
|
I was starting to wonder
|
|
|
|
|
IMO, yes, and no.
Yes, in that recruiting is expensive, so most large companies recruit for the long term. As such, they want to see that you (a) are a decent guy to work with, (b) know something about the field at present, and (c) can master new technologies as they come along. No, in that the recruiters use a filter of 'X years of Y' in order to separate the sheep from the goats.
There is a fundamental mismatch between a large companies' actual requirements and those that the recruiters apply, which leads to much frustration on both sides.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Quote: There is a fundamental mismatch between a large companies' actual requirements and those that the recruiters apply, which leads to much frustration on both sides. Sigh |
Tell me about!
|
|
|
|
|
Interview processes, IMHO, should probably find answers to following questions not in any particular order:
- We have to do work X now. Can this person do it with standards that we follow or like to achieve?
- Once X is over, we need to work on Y and might also get Z to do. Will this person be useful then?
- Does this person look like he can adapt to our work culture?
- Is it probable that this person will be around as long as we would want him to be?
- Does this person look like he is willing to learn new things or rather open to change and criticism?
- He claims to be having X years of experience. Do we see expected maturity levels at this experience?*
However, many a times I have seen a job paired with years of experience. That is sometimes incorrect pairing. A person with any amount of experience can be
- Incompetent
- Rigid in the way he works
- Madly in love with technology he has worked with, hence not open for newer things.
*Technologies may have changed but I believe certain qualities only come with experience.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Quote: Does this person look like he can adapt to our work culture? I tend to view this as can we sit down and have a with them or will a horrible argument be the result... but I'm not managment.
|
|
|
|
|
Why would you go out for with management? What would you b!tch about then?
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
True...I was thinking of one company I worked for where I think I was taken on as I could handle both of the engineers above me. They did not like each other!
|
|
|
|
|
Well in my case it was because they had the expense account and company credit card...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
glennPattonInThePUB wrote: I am starting to wonder if the interview process is more to do with 'can we work with this guy' more than 'this guy has X years of Y'.
Yes, that is the case.
IMO. If new employee is not "fun" to work with, all his experience counts for nothing.
I'd rather be phishing!
|
|
|
|
|
I am now worried about the company who hired me, are they as sick & twisted as me???
|
|
|
|
|
For sure this is true in Asia, for some reason there they really believe it's HR's job to hire staff at any level for any department for any function; even the head hunting firms (premium firms included) that are located there have moved to this model.
Not joking but really don't bother applying if you are ugly, fat, wrong color ... (unless you are family.) Sure some Asian countries have 'anti discrimination' laws, and 'proper ladies' never fart in public.
Hey', it's just my opinion after being there > 20 years, and inasmuch it's one of the top [of many] key reasons why Asia will forever be a follower: they may be faster, they may have more, they are often more efficient, but they won't be first.
|
|
|
|
|
From what I have heard HR try to get themselves in the loop so they are harder to get rid of. Never met one who was any use! Interesting to get Asia view. I think I lost out on one job as I was taller than the guy interviewing me.
|
|
|
|
|
I use the BBC/News website as my home page within Internet Explorer on Win10. Everything is OK until I accidentally close IE. When I re-open it, IE has a lot of trouble displaying my home page again. The speed is very slow to the point that sometimes it won't open at all, even though the URL is displayed correctly. If it does open, using the site is very slow. To fix the problem, I have restart Win10.
Does anyone else experience this problem with their homepage?
|
|
|
|
|
No.
But then, I don't use IE.
Try Chrome: it just works for me!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|