Skip to content
This repository

Move Mediator class to api package #73

Closed
probertson opened this Issue · 2 comments

3 participants

Paul Robertson Shaun Smith Stray
Paul Robertson

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 =)

Shaun Smith
Owner

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.

Shaun Smith darscan referenced this issue from a commit
Shaun Smith darscan moves towards #73 1ce86fa
Stray
Collaborator
Stray commented

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

Shaun Smith darscan closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.