Sometimes I have need to call namespace and class the same. For example, SomeProject.Compiler namespace, containing lots of compiler-related stuff and the main entry point class Compiler. But naming namespace and class name the same is not recommended, as it creates ambiguity and misleads compiler.
Is there any idea, how to name them better?
It is always possible to give general namespace name, which describes all its members. For example, CompilerServices instead of compiler.
Some books say you should write the domain of your company (in the reverse order) before the name of namespace.
Something like com.company.www.compiler
Related
Is there a conflict of behavior for using the Class expression, since it became a reserved word in the latest version of Ecmascript? Can't say if there is identity of grammar between the two contexts, but I guess the built-in noun takes precedence.
JavaScript is case-sensitive. Its class keyword and MooTools' Class identifier don't conflict at all.
If you mean the "classes" generated, I wouldn't try to use one style to subclass a "class" created with the other style (though you might get it to work, particularly if using class to subclass a Class class), but other than that, there's no big conflict. They both create objects with associated prototypes.
I wonder why we have to load an ontology, also provide its namespace while querying it? Why loading the ontology is not enough?
To understand my question better, here is a sample code:
g = rdflib.Graph()
g.parse('ppp.owl', format='turtle')
ppp = rdflib.Namespace('http://purl.org/xxx/ont/ppp/')
g.bind('ppp', ppp)
In line 2, we have opened the ontology (ppp.owl), but in line 3 we also provided its namespace. Does namespace show the program how to handle the ontology?
Cheers,
RF
To specify an element over the semantic web you need its URI: Unique Resource Identifier, which is composed of the namespace and the localname. For example, consider Person an RDF class; how would you differentiate the Person DBpedia class http://dbpedia.org/ontology/Person from Person in some other ontology somewhere? you need the namespace http://dbpedia.org/ontology/ and the local name Person. Which both uniquely identify the class.
Now coming back to your specific question, when you query the ontology, you might use multiple namespaces, some namespaces may not be the one of your ontology. You need other namespaces for querying your own ontology, e.g. rdf, rdfs, and owl. As an example, you can rarely write an arbitrary query without rdf:type property, which is included under the rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns> namespace, not your ontology namespace. As a consequence, you need to specify the namespace.
Well, now as you should know why to use a namespace, then we can proceed. Why to repeat the whole string of the namespace each time it is needed? It is nothing more than a prefix string appended to the local names to use in the query, to avoid writing exhaustively the full uri. See the difference between <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> and type.
Edit
As #AKSW says, as a conclusion, there is no need to declare a namespace in order to work with the ontology but it increases the convenience when working quite often with resources whose URI has particular namespace.
I'm reading from an Oculus Rift and writing via serial to control an Arduino, but I'm having some problems with namespaces since I'm new to C++.
The beginning of my code goes like this:
#using <System.dll>
#include "OVR.h"
#include <iostream>
#include <conio.h>
using namespace System;
using namespace System::IO::Ports;
using namespace System::Threading;
using namespace OVR;
The original error ocurred when I tried to use String, since it is defined in both System and OVR. I changed the code to System::String but now I got an error telling me that System is ambiguous because it is already defined in OVR::System
Is there some way to avoid this conflict? Some way to exclude OVR::String and OVR::System from being affected by the 'using' clause? I can't get rid of one of the 'using' clauses because I have a lot of reference to the members of those namespaces in my code.
First, you can always fully-qualify a name to use it specifically:
::System::String^ string; // this will always work
You can also use specific using directives to disambiguate without having to fully-qualify names:
using ::System::String;
String^ string;
Using directives can be placed at any level and will only affect this level. For instance, if you put one at the global level, all of your file will be affected by it. If you put it inside a function, only your function will be affected by it.
Also, I don't know if you realize it, but you're using C++CLI, an extension to C++ that lets you use .NET classes with C++-like code. This only works on Microsoft platforms.
The OVR namespace includes tons of things which have common names and might conflict with something you're using, so don't import it. In other words, don't do this:
using namespace OVR;
Instead, import the specific OVR items that you want like this:
using OVR::Matrix4f;
You can now using the Matrix4f class unadorned in your code, without having to worry about other types that you didn't import conflicting.
If there's still an issue where you're going to have a conflict (say you need to use the OVR Matrix4f class and your own Matrix4f class) then you have two options. Either accept that you're going to have to use explicit namespaces for one of them, or create typedefs for one of them:
typedef OVR::Matrix4f OVRMat4;
Matrix4f foo;
OVRMat4 foo;
I develop a lot of frameworks for Flash games and applications. I have always prefixed my class names with a random character or two, to avoid conflict with class names that the developer may already have, for example:
class LEntity
Recently I had a co-worker blast me for poor and "annoying" naming of classes who then proceeded to rename every class in the frameworks I've created for people here to use.
I'm having trouble explaining my reasoning thoroughly enough for him to accept what I've done as a good approach.
Is what I've done above actually a bad thing? If not, how can I explain otherwise? If so, why?
Comments are asking about namespaces - I know AS3 in this example has what I know to be called a namespace but I'm not sure if this is the same thing or if it can be used as expected.
Given that Actionscript supports namespaces, there is no reason to use prefixes simply to prevent naming clashes. That's what namespaces are for.
Some people like to use namespaces to significy member variables (ie, underscore prefix, or sometimes m_) and that has some merit, but simply for the sake of name clashing no.
It sounds like you don't quite understand what namespacespackages are in AS3.
An example:
//Class1.as
package com.test.someModule { //This is the package/namespace
public class Class1 {...}
}
//Class2.as
package com.test.otherModule {
import com.test.someModule.Class1; //Class1 can be used as "Class1" now. Otherwise you would do "com.test.someModule.Class1"
import com.test.someModule.*; //You can also use the "*" to "import" all classes in that package
}
I have to agree with your co-worker, your class names are 'annoying'.
In Actionscript 3 we use the package name to define the namespace of a class. If you're not sure what namespace means, take the wikipedia definition (as of the time of writing):
"In general, a namespace is a container for a set of identifiers
(names), and allows the disambiguation of homonym identifiers residing
in different namespaces."
So you will never "conflict with class names" as long as you name your packages correctly. Most developers use what is called the reverse domain notation to name their packages (e.g com.mywebsite.MyGenericNamedClass). Domain names are unique so it's very unlikely you would clash with another class.
As a rule of thumb the class name should be as descriptive as possible, so some of your class names will be the same as someone else's class. Take the default Sprite class for instance:
import flash.display.Sprite;
import uk.co.mywebsite.Sprite;
if you then initialize an object:
var mySprite:Sprite = new Sprite();
The compiler would not know which Sprite you want to initialize (is it the flash sprite or your own custom sprite), and it would throw an error.
The solution is simple: because your packages have been named properly, all you need to do is to use the full class name including the package name to initialize your object:
var mySprite:uk.co.mywebsite.Sprite = new uk.co.mywebsite.Sprite();
var myOtherSprite:flash.display.Sprite = new flash.display.Sprite();
Mind you, you would rarely need to do that. This is only necessary if you want to use those two classes (the default Sprite and your own Sprite) in the same scope. Generally, you would only import your own class:
/* we are not importing this any more
import flash.display.Sprite;*/
//only importing my own class
import uk.co.mywebsite.Sprite;
/* now I can initialize my object without using the full class name, and the compiler knows
I mean my own Sprite class */
var mySprite:Sprite = new Sprite();
I'm reading Robert C. Martins book Clean Code. He writes about a convention not using verbs in class names.
The project I'm currently working on we need to validate and process some xml, so I created something like this
public class XmlProcesser
{
public XmlProcesser(string filePathAndName)
{
}
public bool Validate()
{
}
}
But Uncle Bobs recommendation is not to use "Processor" in the class name.
But what should I call it? Xml is no good, because I'm using the .net class xml a lot in the code. I thought about XmlHandler but I guess that is worse than Processor since "handler" is something else for a programmer.
How do you do? Do you use verbs in your class names?
Naming is important. Heck, T.S. Eliot and Andrew Lloyd Webber made fortunes from The Naming of Cats. But Martins' point isn't about not using verbs - it's about object-oriented thinking. Classes are patterns for instantiating objects. Objects are things. Are similar things better described by their behaviors or by their names?
Am I a carnivore? Yup. But I also write programs. Am I a programmer? Yup. But I also voted for Obama. Am I an Obama supporter? Yup. But ... In the end, I am a person. More correctly, I am an instance of the class[1] HomoSapiensSapiens. And HomoSapiensSapiens has many, many, MANY methods, all of which have verb-like names to them. Like HomoSapiensSapiens.EatBacon(). Like HomoSapiensSapiens.WriteGoodCode(). Like HomoSapiensSapiens.VoteDemocratic(). etc.
Martin's big point is that if your classes are best named like verbs, you're thinking about your classes all wrong.
[1] "class" in the OO meaning, not the Kingdom/Phylum/Class biological meaning.
As mentioned in the comments: Processor is derived from a verb, not a verb. Therefore Processor is an Ok name for class.
XmlProcessor doesn't really tell you much about the class. Ok, it is dealing with xml, but what does it do? Validate it? Forward it? Parse it? So it is very likely that there is a way better name around the corner
Taking the SOLID principles seriously you often end up with classes like
XmlProcessor{
public void process(){ ... }
}
or
CalvinTransmogrifier{
public Calvin transmogrify(Calvin c){ ...}
}
At that point you kind of reached the border between OOP and Functional Programming. And one can make an argument that
Transmogrify{
public Calvin do(Calvin c){ ... }
}
is an acceptable way to name things. If this is actually the case depends on your language of choice. E.g. in Scala if you can use 'apply' instead of 'do' and actually call the apply mothed like this
Transmogrify(new Calvin)
which at least I consider nicer then
Transmogrifier.do(new Calvin)
Yeah, it's a bad habit to name a class with verbish words like "Processor". What does the XMLProcessor you made actually process? Hold that thought. You said there's already a class named XML, otherwise you would use that. The problem is exactly that frustration you felt having to come up with a different name. The XML class is looking you right in the face, saying "I am XML, I am awesome, do not try to replace me, because I can process XML despite my short name. Don't think for a moment that I can't "process" something, bucko. " (if classes could talk and were annoying).
So, now, explain what your XMLProcessor class does that the standard XML class does not do. That's the crux of what you are missing. Perhaps you can extended the XML class to do whatever it is that the XMLProcessor does. Or perhaps you can create a new class that derives from the XML class, and name it based on what it processes that the base XML class cannot.
For those that "disagree with Uncle Bob", that just means you don't understand. It doesn't mean you are right.