Well, having one stored procedure for each possible search parameter would be a REAL horror, IMHO. You can get to the hundreds of procedures really fast. I would likely have more than one parameter in the sproc, and default values, so I could write:

EXEC GetClientDepartments @accountNumber = 'xxxxxxxx';
-- or...
EXEC GetClientDepartments @catId = 'xxxx';

t-SQL code can get really, really messy if you don't pay attention. But, other than that, the code is not really an horror (t-SQL code quality is a lot lower than what you're expecting). My 2c.

I was going to suggest the same. Basically, instead of writing someType.implements(interface) you write interface.IsAssignableFrom(someType) . For some reason, when I encountered this method the first time, I thought that an "Implements" method would make more sense, even if they are basically the same.

PIEBALDconsult wrote:

Or, better, write a method and eliminate the repetitive code.

This.

No. In a vacuum the speed of light is constant. No exceptions. The light can be bent by mass, but not slowed down. The universe is expanding, yes, so the light is going to need more and more time to travel across it, but the speed is still constant. No implications about it. In fact, relativity states that the speed of light in a vacuum is the ONLY thing that remains constant in different reference systems. Which can get you down in a very deep rabbit hole: time shrinks and space expands, but whoever are you, wherever are you, you will still get around 300'000 km/s for a ray of light in a vacuum.

Agreed, 100%. :thumbsup: I was not telling in any way it's a good idea to use a lot of statics. I was just referring to an "object" strict definition.

Either you're a troll or you don't know what you're talking about. Strings in C# are immutable anyway. But you can assign to List and array in which way you want.

List<string> list = new List<string>() { "a", "b" };
list\[0\] = "I";
list\[1\] = "work";

string\[\] array = new string\[2\] { "1", "2" };
array\[0\] = "Me";
array\[1\] = "too";

Hello? You there? You want a C++ style vector to store 2 values? Why should it change in size? You didn't studied even the stl, did you? This just proves that you don't know anything about the things you're writing and just keep whining about everything you don't get right in the first place (by pure chance). Why List<string> isn't fit? Or ArrayString, if you need not type checking? Why string[2] is not ok? If the 2 elements are really different things, why not write down a class with 2 properties? Noooo, let's just pretend you already know everything you need and bash the framework on the internet. I hope I'll never have to maintain your code.

99% correct. Everything is right, except for the first line: "Not at all". ;P They are implemented differently, yes. But this has nothing to do with the definition of Object. You seem to fail to completely grasp the difference between the concept of object and the implementation of the concept in the language. If "An object is something that has methods and properties", you must accept that classes in C# are, in fact, objects. Special ones, implemented differently, but the concept has nothing to do with the implementation. Static methods can access static variables and nothing else. This is the exact definition of object. Right or wrong, useful or dangerous, like it or not ;) I agree with everything you say, but it's not a point, just a technical digression. Classes are objects? Let's see... It has properties? Mmmmm, yes, it can. It has methods? Again, yes. Ipso facto, in C# a class can be an object. Everything else is simply judging the pros and cons of the actual implementation (which I agree with you 100%). Bye!

There is no point in what you're saying. There wasn't before and for sure there isn't in this. What do you have to do with that data? It's an x and y coordinates (like a vector) or it's simply two strings? Why an array string[2] is not ok? What you need to accomplish? And why aren't you creating a simple, 5 lines class to do that? With 2 properties x and y? Do I have to explain you the difference between those 3? It seems you cannot read the documentation... Don't blame the language, blame the programmer. Stop whining and read a book.

Yes, of course. C++ is so elegant that his grammar is undecidable, and no IDE in the world can give you a decent code completion. But maybe you're Klingon and you remember variable names by heart. C is elegant, yes. Just as an haiku. I completely enjoyed writing really quick, incomprehensible code that did simple stuff in clever ways, but designing UIs in C or C++ is an exercise in pain. Not mentioning organizing and building complex projects. C++ templates can do some clever stuff, but generics are pretty similar and less prone to breaking apart your build time. The only thing I miss in C# are mixins, but they are hard to manage even in C++. Pointers are in C# too, but you don't need to use them, usually. You can, but only if you have tight loops to be optimized. Friend is useless if you have internal members and friend assemblies. And private is considered more valuable than it is and not unit testable. Oh, and if "few libraries" means the single most extended library in existence yes, you are right. To one that makes this kind of statements, I can only suggest to (choose one in three): - RTFM and stop blaming others for what you get in the toolkit, instead of having to roll your own. - change language. Maybe the kind of stuff you're doing is not best suited for C# (I doubt, but...) - write your own language. You seem to be a world class language guru. Way better than that M$ scum. For sure you can tackle that task. A language is a tool, if you can't do stuff and blame the tool, either you change it or learn to use it. Blaming is easier (I remember people complaining about that stupid C compiler that was continually raising segmentation faults). Good luck!

Oh, and BTW KeyValuePair is not a vector. It's only a Dictionary item. You could use it to store two strings, but you probably would be better set implementing a class with two members, x and y.

So you're telling me you needed a screwdriver, but you don't know what a screwdriver is. So you googled for it and picked up a drill. Then you found out that it didn't worked to do the job you need. And you blame Microsoft for this. I suggest you could read "The Pragmatic Programmer". Look, I'm not a MS fan boy, I think many libraries MS is pushing (or where pushing) are crap. But there is a core of consistency and completeness in the .NET framework that I never found out in other core libraries. And an elegance in C# that is unknown to Java. If you don't agree, tell me a better language to do the same kind of stuff you can do in C#. Currently, you seem to bash M$ just for the sake of your incompetency (literally: you're not competent regarding the job you do). I love Python (but it's library is light years lagging on naming conventions), I enjoy JavaScript (but you must know what works and what will break your programs), but the building of the .NET Framework is a major accomplishment.

In C#, classes can have properties and methods: they are called static properties and methods. They can be manipulated at run time, exactly in the same way as instances: you can change property values and call class methods. There is no dynamic typing in C# (except for the dynamic type, but let's ignore this for the sake of this discussion). So, a class in C# can be an Object (I was going to write "is a", but "can be" is more correct), as for the "object" definition.

Take no offense, but you don't know what you're talking about, don't you? Mutable Tuples are called lists and/or classes. Having Tuples is great if you need to have a Dictionary which happens to need two keys: you don't need a custom class or some other custom solution, you just use the tuple as key. Mutable data means the hash will change, so you cannot. Read Immutable as hashable. It really makes a LOT of sense to have tuples. You just have to learn why they are there in the first place and you'll discover that the .NET Framework is one of the best around. And IMO the best, period. My 2 c: Convert is a fossil from 1.0/1.1 era. Never used it since generics went out.

Object is an heavily overloaded term. So, let's try to put things into perspective. "Object" was first introduced as a CONCEPT, as in Object-Oriented Programming. In this model, you have "stuff", which we'll call objects, that implements a program structure and logic merging procedures AND data on the same "thing". Or object, so to speak. In this new paradigm, we call procedures as Object Methods, and data as Object Properties, linked together as it makes more sense (before this the paradigm said you have code structured in procedures that manipulates data, which existed independently). Then, based on this conceptual model, a lot of really smart people created computer languages. Each one of them used this new paradigm as it seemed fit to solve problems. So "objects" morphed into Classes, Instances, hierarchy, etc. But, let's face it: Object sounds a lot better than Instance or Class, so, sometimes, people used the abstract concept of object to refer to something that was actually implemented (like Bruce Eckel in the quote from before). So, the answer to "what is an object?" is: Anything that has Methods and Properties, merging those two really different things. Really, really simple. You're asking the wrong question: An Object is NOT a Class, nor an instance. Exactly like as a function is not an Algorithm. A function can implement an Algorithm, pulling the concept into the "real world", even if not in a tangible form. But in some languages a Class IS an object (e.g. if you have static methods and properties). In .NET, both classes and class instances are Objects. In Python, EVERYTHING is an object. Conclusion: it's more a matter of asking the right questions.

Yes, it is so: i, j and k are standard notation for mathematical arithmetic progressions and series. From well before FORTRAN. But FORTRAN was designed by mathematicians, so we programmers are carrying over the notation. a,b,c -> constants x,y,z -> unknown terms (or real coordinates in cartesian plane) k,j,i -> INTEGER indexes or vector coordinates. I think Gauss was already using this conventions, more than 100 years ago. Gauss wins. As always.

It depends: having a completely distributed source control system is gold, for me. Which happens also to be blazingly fast, btw. Oh well, whatever.

Heat. It's in the quote too!

Or (untested):

for(int i = 0x80; i > 0; i >>= 1)
{
cout << (num & i) ? "1" : "0";
}

Dunno if the code spared is worth it, though.

Well, Order By is of some use, even in views. But it should ALWAYS be paired with a TOP(X).

SELECT TOP 100 PERCENT *
FROM Somewhere
ORDER BY whatever

is a true, classic, horror.