switch(s) {
case null: return false;
case "y": return true;
default: return false;
}
The broader issue is that Java handles null inconveniently.1) Every object can be null, switch requires the argument to be non-null, and the type system doesn't warn you when NPE are possible. A type system which handles nullability could fail to compile if 's' is nullable. Kotlin does this, and it let's you opt-in to the NPE with some convenient syntax:
switch(s!!)
2) It's inconvenient to handle null as a value. To properly handle the null case without throwing, you need to do one the following: if(s == null) { ... }
else switch(s) { ... }
switch(s == null ? "some-default" : s)
The first way can be made more convenient if you change switch to work on nullable values. The second way is inconvenient, so people generally skip it. If you want switch to only work on non-null values, there're more convenient syntaxes to handle null, such as the 'elvis operator': switch(s ?: "some-default")
Optional.ofNullable(s).map(i -> {switch (i) {...}}).orElse()
That's probably because they are pushed by their families, "go and study IT, this is the best paid job at the moment". That doesn't mean that the value, skills, abilities of the new graduates will increase, I tend to believe the opposite.
So even if families pressure their kids, they will not be able to get an admission in these institutes unless they demonstrate required skills.
Here are past exam papers - https://www.jeeadv.ac.in/Archives-Past-Que-papers.html
For value, skill, and ability, please google the research done by the students at these universities and the firms that hire these students.
I'm very sorry if I've misquoted you or quoted you out of context. I'd certainly correct them instantly if contacted. I've searched my email and I don't see any corrections, so I'm not sure how I can make amends.
I pull a lot of quotes from a lot of sources. Many thousands a year. My goal is always to highlight ideas that I think might help readers do their job better. Highlight is they key word here. That you say those sort of things often is not surprising. My hope is always readers will be made curious enough to follow the link and learn more on their own.
And unfortunately there is no "they" at HighScalability.com. There's only me and there's only ever been me. So all mistakes are mine and only mine. There's never been much money or time to be as comprehensive as I'd like.
I do the best I can, but I often fall short, no doubt. I'm not a journalist. I never said I was. I'm a programmer. Have been all my life. I started this blog a long time ago. It was just stuff I found interesting. For whatever reason it got popular for awhile so I tried to make something out of it. That, like most of the industry is petering out now, so we'll see what the future holds.
The point about interviews is a good one and one I've wrestled with. Over the years I've conducted a lot of interviews. Much less so lately, and that's for a reason. I've learned that presentations at major conferences are usually the best resources. Presenters put a huge amount of effort into making those talks. And everything they say is open and approved for public consumption by definition.
Interviews with someone like me are often a bother, a time sync, so I don't usually get as much out of them. Interviews have a high overhead, taking a lot of time to setup and there's often a lot of red tape and legal wrangling that must go on to get access and content approval. Which is again, why, presentations are such awesome resources.
This article was derived mostly from people working on a project making a major presentation or from primary sources writing an article. I couldn't do better than that.
And regardless, I would still make mistakes. Believe me. It's surprisingly hard to make sense of an interview and turn something from thread mode into document mode. That process is an error prone one because I have to fill in the gaps and there are always gaps.
It's rare that I've ever just published an interview. I don't think they are that useful in general. I want people to read a highly condensed document they can get something concrete out of with minimal effort or just ignore easily if it's not relevant to them. The strange style I've developed reflects that goal. This article was of course different because it has a different audience.
So again, I apologize. But I guarantee my mistakes are never intentional, never for money, and never for lack of caring or effort.
But I still write them because situations arise where you do need to change the nature of that property, sometimes dynamically, and then it's suddenly worth it. You can, for instance, change a getter and none of the class's clients need to know or care about the change.
Though I haven't used Groovy much I like their approach to this: "Although the compiler creates the usual getter/setter logic, if you wish to do anything additional or different in those getters/setters, you’re free to still provide them, and the compiler will use your logic, instead of the default generated one."
It may be boring to you, and that is ok, but it does not negate the fact that it is a challenging field and demands immense hard work to be one.