Move Mediator class to api package #73

probertson opened this Issue Apr 10, 2012 · 2 comments

3 participants


When I first created a Mediator subclass, I saw that the import was for a class in a *.impl package and I thought I had imported the wrong class by mistake. I had noticed that pretty much every other interface I used was in an "api" package (or else in the root of a package), so I had developed the mental model that the "api" packages were the ones I was supposed to use and others were "internal" and to be ignored by people who don't understand them.

With that in mind, I propose that the Mediator class should be moved to the robotlegs.bender.bundles.mvcs.api package, or else to the robotlegs.bender.bundles.mvcs package, depending on what else ends up in that root package.

In the interest of full disclosure, here are the biases and prior experience that lead to my mental model, which may or may not apply to a typical RL user:

  • I had already browsed around the RL source a bit, so I had picked up on the fact that most extensions (and probably other parts of the code) use the api/impl [and dsl] packages to divide up their parts.
  • I've read discussions in the RL1 knowledge base about package structure, including the recommendation by @Stray to use "functional module" packages with api/impl subpackages -- so I already had an understanding that "api" means "okay to use" and "impl" means "stay away from this one".

As I've thought about this I've realized that the mental model that RL actually uses is probably "api" for interfaces, "impl" for concrete classes. In that case it makes sense for Mediator to be in impl. However, the distinction between interfaces and concrete classes isn't particularly important to me as a new RL2 user trying to figure out my way through the newer, much larger set of packages and classes. Rather, I really want an easy way to know if a type (class or interface) is something that I'm meant to use, or something that I should leave alone until I understand the inner workings better. To me the "api" versus "impl" packages provide a useful construct for that distinction.

Complete side note: @Stray your preso on "Robotlegs and your brain" has helped me immensely with the meta-analysis required for this issue description =)

Robotlegs member

I fully agree. The packaging is not that helpful at the moment. We'll run through and ensure that all user implementables/extendables are in api packages.

@darscan darscan added a commit that referenced this issue Apr 10, 2012
@darscan darscan moves towards #73 1ce86fa
Robotlegs member

+1 anything that is "normal" use should be in the api package. thanks Paul (and cheers for the nice comments about my preso!)

@darscan darscan closed this May 7, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment