Towards more flexible, portable package naming...

[daveystew]

I want to float something out there and see if it sinks or swims...

I would argue that a significant proportion (say, 50%) of files within a project are probably pretty general, and are concerned with everyday tasks, albeit slightly customised to the project and client in hand.

I would also say that it takes 2 or 3 projects before sets of classes can be considered road tested-enough to warrant being refactored into an external Library.

This being the case, that 1) classes are general, and 2) classes really need to go through several project iterations, I find it really strange that developers are SO ingrained with locking classes into fully qualified namespaces from the word go:

com.client.project.display.components.dropdown.Dro pDown

I would suggest that the following is sufficiently collision-proof, inherently more flexible, transferable between projects, and less fragile when it comes to refactoring:

display.components.dropdown.DropDown

And as soon as you need components in Project B that you used in Project A, you copy them across and they just work (without feeling out-of-place). And if they work well, and are even improved, simply copy them back to Project A (or on to Project C):


Projects
+- Project A
| +- display.components.dropdown.DropDown
+- Project B
| +- display.components.dropdown.DropDown
+- Project C
+- display.components.dropdown.DropDown

As opposed to fully-qualified project paths, where code is pretty-much locked to a single project:


Projects
+- A Project
| +- com.aproject.display.components.dropdown.DropDown
+- Another Project
| +- com.anotherproject.display.components.dropdown.Dro pDown
+- Yet Another Project
+- com.yetanotherproject.display.components.dropdown. DropDown

Of course, once the code has gone through a couple of project lifecycles, if it warrants it, promote it to a fully-qualified com.yourname.Library.

This is certainly not intended to be a poor man's source control, more a flexible way to pick and choose, iterate and improve code in a non-exclusive way as your experience develops across a range of projects .

In my experience, as long as you code cleanly and in a loosely-coupled, manner, there's nothing to lose and lots to gain.

Anyone care to comment!?

Cheers,
Dave

[tadster]

I think I agree 100% with you.

I tend to always think that less is better, my packages are never more than 3 deep, just becuase, well, I'm lazy.

But, I always try to code in such a way that anything I make could be used in any project, like you say, once it's been 'road tested' enough, or if I see that it can be abstracted down more so that it will fit with any project, then I put it into a bigger library.

Edit:

But I don't put multiple projects in the same package.

[daveystew]

Yeah, it just makes more sense doesn't it.

It's annoying when working with others who want to put everything into locked-in packages and think anything else is "wrong". My productivity goes right down :(

[damTyD]

I'm curious, why does everyone put their packages in a com directory?

[maskedMan]

I'm curious, why does everyone put their packages in a com directory?

Not everyone does. Sometimes it's an org directory... or net, or nl, or be, or de, or us, or whatever top level domain you're using for your website.

That said, it's because the package name is, by convention, your website's domain name starting from the top level domain and going back towards the http.

So if I were to release a library from http://www.scriptocalypse.com it would be in the com.scriptocalypse package.

[daveystew]

I'm curious, why does everyone put their packages in a com directory?

Putting packages in a structure like this, assuming you own and use your own domain name, guarantees that the class' namespace will be unique, and there could be no collisions with other packages.