This question already has answers here:
C# namespace alias - what's the point?
(11 answers)
Use of Namespaces in C#
(6 answers)
Closed 8 years ago.
I searched many articles to understand the concept of namespace? But I could not understand.
Can anyone explain the concept of namespace with simple example? Why do we import namespace?
The following is pseudo-code, I hope it's clear
namespace1.SomeClass
namespace2.SomeClass
var x = new SomeClass(); //which class are we trying to instantiate?
var y = new namespace1.SomeClass(); //now compiler and everyone else knows
A namespace is used to organize objects in categories and control the scope of objects.
More details about .NET namespaces on : http://msdn.microsoft.com/en-us/library/0d941h9d
Notice that the namespace concept is not limited to .NET but to many programming languages.
Why Namespace?
Namespaces are used to organize code. It lets you organize code and gives you a way to create globally unique types and avoid name collisions.
e.g.
Suppose, you have created a class Foo in your code. In same project, you are using some third party library, in which also a class with same name exists. In this case, when you are referring class Foo, compiler won't be able to resolve it.
But, this problem can be solved by namespaces. The Foo class in the library you are using, belongs to some namespace specified by developer of it. (Usually, it contains company name or something unique identifier). And your Foo class belongs to namespace you have specified. So, at the time of using it, you can specify fully qualified name of the class like <Namespace>.Foo. Which will make it easy for compiler to resolve reference.
Also, you yourself can categorize your classes using namespace to bifurcate it according to their purpose. Which will be easier to maintain. (e.g. CoreFramework.Foo, UIHelper.Bar, etc...)
Why do we import namespace?
Now, at the time using class you have categorized by namespace. You will have to tell compiler in which namespace the referring class contains. By default, compiler looks for the classes in same namespace. If the class you are referring belongs to another namespace, either you will have to specify fully qualified name of the class (i.e. Namespace.Foo) or you can inform compiler at the beginning of the class by using import statement that, code withing the class contains references to the classes belonging to this namespace.
Related
I need to access class A 's private member in class B 's function and I want to use friend class. however, it seems can not be used as the c++ way .
"error C3816" class Class2 was previously declared or defined with a different WinRT modifier
How can I do to solve it?
P.S.: I can not write get/set function in public area, for I do not want class user to know private member .
Keep in mind why you'd declare a C++/CX ref class, it is to allow a program written in another language to use your C++ code. Such a language will not have any notion of the friend keyword, it is highly specific to the C++ language. Only a C++ compiler is capable of enforcing the friend contract. And in fact will not work at all when, say, that client code is written in C#, the CLR strongly enforces accessibility. Accordingly, the metadata format of the .winmd file that's generated by your project doesn't support expressing the notion of friend at all. So the compiler doesn't either.
First check to make sure you are using C++/CX appropriately, only use the ref class keyword if you actually intended to make the class accessible to other languages. Use a regular C++ class, plain class without the ref contextual keyword, if the class is only going to be used by your own code. If it is truly intended to be used as an interop class then you will have no other option but to make the member public.
Access specifiers are precautionary to prevent accidental access and so std C++ & stl performance with specific select CX friends- for say holding xaml binding datacontext containers- is straightforward approach. For whichever reason, VC++ is racist w. r. t. WinRT ABI mingling through OOP. One known alternative is to switch to generative meta programming instead of OO. To do this, keep template member function in the class that wants to befriend the consumer, and specialize this in the scope of the consumer and then onwards use the specialized version from within the consumer. Its sort of hidden from Microsoft family friendship affair.
You can solve this by using
friend ref class Class2;
instead of
friend class Class2
what is the purpose of namespaces ?
and, more important, should they be used as objects in java (things that have data and functions and that try to achieve encapsulation) ? is this idea to far fetched ? :)
or should they be used as packages in java ?
or should they be used more generally as a module system or something ?
Given that you use the Clojure tag, I suppose that you'll be interested in a Clojure-specific answer:
what is the purpose of namespaces ?
Clojure namespaces, Java packages, Haskell / Python / whatever modules... At a very high level, they're all different names for the same basic mechanism whose primary purpose is to prevent name clashes in non-trivial codebases. Of course, each solution has its own little twists and quirks which make sense in the context of a given language and would not make sense outside of it. The rest of this answer will deal with the twists and quirks specific to Clojure.
A Clojure namespace groups Vars, which are containers holding functions (most often), macro functions (functions used by the compiler to generate macroexpansions of appropriate forms, normally defined with defmacro; actually they are just regular Clojure functions, although there is some magic to the way in which they are registered with the compiler) and occasionally various "global parameters" (say, clojure.core/*in* for standard input), Atoms / Refs etc. The protocol facility introduced in Clojure 1.2 has the nice property that protocols are backed by Vars, as are the individual protocol functions; this is key to the way in which protocols present a solution to the expression problem (which is however probably out of the scope of this answer!).
It stands to reason that namespaces should group Vars which are somehow related. In general, creating a namespace is a quick & cheap operation, so it is perfectly fine (and indeed usual) to use a single namespace in early stages of development, then as independent chunks of functionality emerge, factor those out into their own namespaces, rinse & repeat... Only the things which are part of the public API need to be distributed between namespaces up front (or rather: prior to a stable release), since the fact that function such-and-such resides in namespace so-and-so is of course a part of the API.
and, more important, should they be used as objects in java (things that have data and functions and that try to achieve encapsulation) ? is this idea to far fetched ? :)
Normally, the answer is no. You might get a picture not too far from the truth if you approach them as classes with lots of static methods, no instance methods, no public constructors and often no state (though occasionally there may be some "class data members" in the form of Vars holding Atoms / Refs); but arguably it may be more useful not to try to apply Java-ish metaphors to Clojure idioms and to approach a namespace as a group of functions etc. and not "a class holding a group of functions" or some such thing.
There is an important exception to this general rule: namespaces which include :gen-class in their ns form. These are meant precisely to implement a Java class which may later be instantiated, which might have instance methods and per-instance state etc. Note that :gen-class is an interop feature -- pure Clojure code should generally avoid it.
or should they be used as packages in java ?
They serve some of the same purposes packages were designed to serve (as already mentioned above); the analogy, although it's certainly there, is not that useful, however, just because the things which packages group together (Java classes) are not at all like the things which Clojure namespaces group together (Clojure Vars), the various "access levels" (private / package / public in Java, {:private true} or not in Clojure) work very differently etc.
That being said, one has to remember that there is a certain correspondence between namespaces and packages / classes residing in particular packages. A namespace called foo.bar, when compiled, produces a class called bar in the package foo; this means, in particular, that namespace names should contain at least one dot, as so-called single-segment names apparently lead to classes being put in the "default package", leading to all sorts of weirdness. (E.g. I find it impossible to have VisualVM's profiler notice any functions defined in single-segment namespaces.)
Also, deftype / defrecord-created types do not reside in namespaces. A (defrecord Foo [...] ...) form in the file where namespace foo.bar is defined creates a class called Foo in the package foo.bar. To use the type Foo from another namespace, one would have to :import the class Foo from the foo.bar package -- :use / :require would not work, since they pull in Vars from namespaces, which records / types are not.
So, in this particular case, there is a certain correspondence between namespaces and packages which Clojure programmers who wish to take advantage of some of the newer language features need to be aware of. Some find that this gives an "interop flavour" to features which are not otherwise considered to belong in the realm of interop (defrecord / deftype / defprotocol are a good abstraction mechanism even if we forget about their role in achieving platform speed on the JVM) and it is certainly possible that in some future version of Clojure this flavour might be done away with, so that the namespace name / package name correspondence for deftype & Co. can be treated as an implementation detail.
or should they be used more generally as a module system or something ?
They are a module system and this is indeed how they should be used.
A package in Java has its own namespace, which provides a logical grouping of classes. It also helps prevent naming collisions. For example in java you will find java.util.Date and java.sql.Date - two different classes with the same name differentiated by their namespace. If you try an import both into a java file, you will see that it wont compile. At least one version will need to use its explicit namespace.
From a language independant view, namespaces are a way to isolate things (i.e. encapsulate in a sens). It's a more general concept (see xml namespaces for example). You can "create" namespaces in several ways, depending on the language you use: packages, static classes, modules and so on. All of these provides namespaces to the objects/data/functions they contain. This allow to organize the code better, to isolate features, tends for better code reuse and adaptability (as encapsulation)
As stated in the "Zen of Python", "Namespaces are one honking great idea -- let's do more of those !".
Think of them as containers for your classes. As in if you had a helper class for building strings and you wanted it in your business layer you would use a namespace such as MyApp.Business.Helpers. This allows your classes to be contained in sensical locations so when you or some else referencing your code wants to cosume them they can be located easily. For another example if you wanted to consume a SQL connection helper class you would probably use something like:
MyApp.Data.SqlConnectionHelper sqlHelper = new MyApp.Data.SqlConnectionHelper();
In reality you would use a "using" statement so you wouldn't need to fully qualify the namespace just to declare the variable.
Paul
Is there any way I can get a list of all the classes in a particular package?
I know getDefinitionByName, getQualifiedClassName, and getQualifiedSuperclassName in flash.utils can find me a class, but I can't find anyway to find all the classes in a package at runtime.
No, ActionScript reflection is limited to the three functions you mentioned and flash.utils.describeType(object:*).
I have a .dbml file which of course contains the auto-generated classes based on my tables.
I would however, like to extend them to my own classes. Typically I design such that each of my tables get their own namespace in their own folder containing all of their associated dao and service classes. So if I am dealing with a page that only has to do with 'customers' for instance, I can only include the customerNS.
But when using LINQ I seem to be unable to do this. I have tried removing a default namespace from the project, I have tried putting the .dbml file into it's own folder with a custom namespace and then adding a 'using' statement, but no nothing works.
I also saw the Entity Namespace, Context Namespace, and Custom Tool Namespace properties associated with the .dbml file and tried setting all these to names x and trying 'using x' in my other class to allow me to extend partial classes, but it just doesn't work.
Is this possible or do I have to keep all extended partial classes in the same namespace as the .dbml file?
If the types don't have relations the answer is simple: use multiple dmbl files. If you need relations and you also want multiple namespaces read on.
You might be able to get this done with a T4 template file. In VS2010 there's a template to create one (it's called a generator template or something). For VS2008 you can find one on codeplex
The changes you'll need to make to the standard template is you need to make sure that all properties use fully qualified names (because the related types are now in different namespaces). And for most control you can probably skip the namespace info from the generated classes (so you can define it in your partial classes).
You have to keep all linq classes in one namespace. Why you trying to put DO classes in different namespaces?
Tutorials usually don't deal with scope in Actionscript. Can you point me to some documentation and/or explain what should I know about it. I want to avoid problems arising from certain classes are not visible at certain places.
These should help.
Function scope:
http://livedocs.adobe.com/flex/3/html/help.html?content=03_Language_and_Syntax_21.html
Packaging and namespace:
http://livedocs.adobe.com/flex/3/html/03_Language_and_Syntax_04.html#119303
You're a bit vague, but hopefully I'm getting you ;)
Scope for classes are generally pretty easy to handle, it mostly comes down to packages.
Packages are created in a simple tree structure, and in ActionScript3 the filestructre has to follow the namespaces. Which makes it even easier.
You can access any class from anywhere, but if it's in another package you will need to "import" the class. This is done by writing an import statement in the beginning of class or interface where you need to use it. Like so:
import flash.display.MovieClip;
There is an exception to this rule, a class can be declared with the internal keyword, in which case the class will only be available within that package. This is mostly used for helper classes.
Basicly you should not worry about classes not being available.
NB:
You create package with the package keyword.