I want to (am trying to) make my code more readable. I have been using the following class aliasing.
using Histogram = EmpiricScore<int>;
using FeatureHistogram = Dictionary<string, EmpiricScore<int>>;
But I think something like (note: I'm attempting to describe FeatureHistogram
in terms of Histogram
here, rather than EmpiricScore<int>>
):
using Histogram = EmpiricScore<int>;
using FeatureHistogram = Dictionary<string, Histogram>;
Seems more readable (the dependencies can go much deeper, what if I create a Hierarchical feature histogram), and easier to re-factor (if I happen to decide that the name Histogram is unfortunate). But the compiler won't do it. Why ? Any way to circumvent this ?
Creating new classes seems a little bit overkill...
I don't find it an overkill because if you design a class which wraps the
Dictionary<string, Histogram>
(your class should implementIDictionary<string, Histogram>
and have a privateDictionary<string, Histogram>
property backing the data) you're enforcing reusability, which is one of the best selling points of object-oriented programming.For example, your implementation would look as follows:
But the compiler won't do it. Why ?
compiler won't do it according to C# specification 9.4.1:
A
using-alias-directive
introduces an identifier that serves as an alias for a namespace or type within the immediately enclosing compilation unit or namespace body.options: 1. as
M.kazem Akhgary
suggested in a comment, define new namespacedemo