First off, let me mention the concept of namespaces in programming languages. Programming languages allow users to define variables, functions, classes, etc. with names (identifiers). For example, there may be variables named x and userName, functions named CalculateVolume and PrintDetails, and a class named File. In any program of sufficient complexity, there is the potential for the same identifier to be used in multiple places. Some potential complexity is resolved simply by the concept of scope. For instance, the identifier for a variable defined inside a function only applies within that function. Scope isn't sufficient to fully resolve the problem in a complex program though, particularly when third-party code is involved. You may have a function named CalculateVolume and a class named User in your own source code, but you may also be utilizing libraries, one of which contains a function named CalculateVolume and another which has a class named User. How does this potential ambiguity of sorts get resolved?
Classes and/or namespaces, depending upon the language in question. Namespaces provide a way of placing a set of classes, functions, variables, etc. into a named context such that they can be qualified. For example, the vector class in the C++ Standard Template Library is a type of list structure that exists in the namespace std, and so may be qualified as std::vector. There may also be a vector class defined elsewhere for purposes of linear algebra; assuming it existing in the algebra namespace it would be algebra::vector. Classes can also be used to help resolve the potential conflicts between identifiers.
The identifier of function defined within a class exists within the scope of the class, and so can be qualified by the name of the class. Assume there is a class User which has a function named GetLastLoginTime, If the function is an instance method of the User class, and there is an instance of the User class named aUser, then the function would be called as aUser.GetLastLoginTime(). On the other hand, not all functions contained within a class are instance methods. Some are what are known as static methods. Static methods have a variety of purposes, but one of the purposes is to simply group conceptually-related functions into a common place.
An example of this use can be found in the C# and Java programming languages, with the Math class. A number of useful mathematical functions such as the trigonometric functions (sine, cosine, tangent, and their inverses), exponentiation, logarithms, square roots, etc. are static methods within a class named Math. To use these functions, they must be qualified with the class name . For exmaple, in C# to make a call to the function to calculate cosine for an angle of 1.2 radians you would call Math.Cos(1.2). Simple enough, but long formulas and complex equations often become longer and less readable than they otherwise must be.
Starting with C# 6.0, there is a new language construct known as using static. Since its inception, C# had a language construct known as using which allowed programmers to bypass the need to qualify class names with the namespace. For example, rather than referring to calling System.IO.File.Exists, if using System.IO; was specified at the top of the file, File.Exists could be called without the additional qualification. The using static construct extends that concept to static methods of classes.
I've only been using this feature for a short time, and I like it. Calculations that involved lots of common math functions used to be far longer and are now shorter and easier to read, since I simply add a using static System.Math; statement at the top of any C# file where there are lots of calculations. In projects where I've got a bunch of common utility functions that are widely used, it also very handy at simplifying code. In some of my experimental code where a strict object-oriented approach is either not a good fit or simply premature because structure is an open question until technique is understood, it allows me to organize and modularize code into classes while keeping the the individual code statements clean. On the other hand, it can lead to the very same ambiguities due to identifier conflicts that namespaces, classes, and qualifications helped to resolve, so it should be used with care.
You'll probably be able to see some more examples of this once I get the planet generator finished and released. Until then, I hope you find some use for using static, or at least found this post interesting. Good bye for now.
No comments:
Post a Comment