On 27/03/2013, at 10:28 PM, Adam Murdoch <[email protected]> wrote:
> > On 28/03/2013, at 9:13 AM, Luke Daley <[email protected]> wrote: > >> >> On 27/03/2013, at 4:59 PM, Adam Murdoch <[email protected]> wrote: >> >>> >>> On 28/03/2013, at 1:33 AM, Peter Niederwieser <[email protected]> wrote: >>> >>>> Adam Murdoch wrote >>>>> We could possibly implement this by traversing and inspecting the static >>>>> dependency graph between types, so that, for example, a type that is >>>>> reachable from a Task type cannot then depend on any Task or Plugin types. >>>>> >>>>> I think, however, naming scheme is the simplest option - this might mean >>>>> prefixing or suffixing types with their role, or separating roles into >>>>> packages, or some combination. >>>> >>>> If we truly need to know the roles at compile time, and not just for plugin >>>> and task classes, >>> >>> Just to clarify: We don't necessarily need to know at compile time, but I >>> do want the CI build to fail if any of these things are tangled. So, >>> there's some kind of static inspection going on. >>> >>>> then a package naming scheme is the clear winner for me. >>> >>> The question then is what the scheme should be. >>> >>>> Question is how to make things work for all the existing code that doesn't >>>> fit the agreed upon naming scheme. >>> >>> If we go with a package naming scheme, then for incubating classes, we'll >>> move the classes to the new packages. For public classes, we'll can exclude >>> them or make the inspections tweakable (as the existing classes are already >>> separated to various degrees). >>> >>> If we go with some source/bytecode analysis, then the existing stuff should >>> just work. >> >> What are the downsides of this approach? > > We need some way to figure out which group a given class lives in, so it > depends a bit on how we decide to do this. > > Right now, we can figure out that a class is-a Task or is-a Plugin. We can > continue to use package naming scheme to separate out the internal stuff. So, > we might assume that anything that isn't a Task or a Plugin or isn't internal > is a model class. It doesn't quite allow us to really separate out the model, > but might be good enough. > > We could potentially mark up model types with an annotation or interface, so > that we can separate them out from the 'everything else' bucket. There are > other reasons why this might be useful, but I think they're off in the > distant future. > > The main downside is that we have to implement this scheme, whereas the > naming scheme checking already works. The package solution still just doesn't sit right with me. I can't think of much precedence for this kind of thing (attaching semantic meaning to package namespacing). I also don't think it's very evolvable. If we decide we need further categorisation, then we have to deal with the backwards compatibility implications of moving existing classes around. If we use an annotation or type based approach, then it should be easier to make changes. We should try and claim the weakest facts that we strictly need here. Moving things into packages feels like it's saying too much to me. In terms of build time checking, we could implement the visibility constraints by source sets and compile stages. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
