As my journey continues in learning about working with other developers, I ran into the com. prefix question. A lot of Java people I had asked about why do they do that prefixing of com to their class paths replied, “Because it’s industry common practice.” Hogwash… OOP is industry practice, right? Bleh.
People who say things like that to me quickly turn me off to doing the “common practice”. It’s the same reason my math teacher disliked me in her class in school; I’d always ask “I know we’re solving a problem, but what problem is this equation solving?” I always wanted to know why algebra and geometry was important; where would you use it, and if her answer didn’t suffice, then screw it, why waste time on it?
I’ve grown a tad more mature since then; instead of asking 1 person, I ask many. I know someone’s got the answer, it’s just a matter of finding someone who does, or who does AND is willing to part with it.
I figured since Macromedia doesn’t do it, and I see no point of com, why should I?
One of the developers I work with who is helping me replied:
– in java, if you deploy code bases server-side, you’ll have different packages for different projects and/or server configurations. So, com will be for the site.com, whilst org. will be for the site.org; the open source version.
So, it’s more about an implementation detail made more encapsulated into a high level package path giving it name and purpose vs. “just because everyone else does it.”
Granted, Flash code doesn’t get deployed server-side (but Flex does, and I’ve made Central run as a server…), but it does get deployed client-side. Case in point, if we decided to release an open-source version of our code from here at work, we’d release it as org.roundboxmedia instead of com, since com applies to our commercial products that either we own, or the client does (although, from my understanding, we own most of the code and sell it as various products), whilst org would be us supporting an open source initiative(s).
So:
– name context helps in server deployment
– name context helps in code distribution to various clients
That was enough to sell me!
* B, sorry for the late response; took me awhile to gather my thoughts on this.
Anyone else got other reasons?
Not sure if im stating the obvious or not, but i personally use the domain name of my website in package names to ensure that the package name and thus the ‘namespace’ that my classes are executed in are unique and i can therefore safely assume that the code will run without any conflicts with other code in the movie, which ‘may’ be written by other people either in my team, or an open-source library from the web.
‘Why a domain name?’ A domain name not only adds indentity to code if you share it open-source, it also guarantees that the package name is unique, as only one person can own a domain name at any given time. Granted, somebody else could use your domain name as their package name, but a person would only do that if they were purposely trying to cause conflicts with your code.
I believe it was Sun that originally asked people to use their reverse domain name as the namespace for their code when writing Java applets, to solve this problem and i guess it just became a standard from there.
I see no reason, why i shouldn’t use a domain name, so ive never questioned it, can you think of something better that solves the same problem? Random characters maybe? nahhh…
At first, it was our company name:
’roundboxmedia.controls’
Just like:
‘mx.controls’
But, after discussion I see the point; I also see, after your explanation, how a domain name adds 1 extra layer of uniqueness.
I wrote something about that when somebody from the community asked me the reason.
Class naming convention, Reverse domain