On 20/08/2012, at 9:05 AM, Szczepan Faber wrote: > I think I understand Luke's concern, yet I have a feeling the extension > postfix has little actual impact on modelling.
I think it can have as much impact as any name. > Poorly written plugin will will have week model regardless of the name for > the extension class. So don't try? > The extension class name is not really exposed to the build itself so the > biggest modelling effort is to design the DSL People look at our codebase to see how they should be doing things. That's where the naming comes into play. > (i.e. the methods/properites/nested types on the extension object). I would > expect the meaty plugin logic to implemented outside of the extension class, > leaving the extension object only responsible for the build dsl (that is > 'extending' it... ;). > Capturing the context in which the class is used in the class' name sometimes > makes the codebase easier to grasp. Hence I don't think Extension postfix is > such a bad thing. So are we saying that in every case what gets injected into the build language should be some kind of facade or adapter? Or are we saying that unless it's describing something more tangible in the domain (e.g. source set, custom packaging) it should be an “extension”? Anyway… I'm not going to pursue this issue any further. > > That's just my POV :) > > Cheers! > > On Thu, Aug 16, 2012 at 11:55 AM, Luke Daley <[email protected]> > wrote: > > On 16/08/2012, at 8:43 AM, Sean Reilly wrote: > >> If the class' purpose is to provide DSL elements, then how about naming it >> FindBugsDSL? > > That's better than extension for me. > >> >> On Wed, Aug 15, 2012 at 9:16 PM, Adam Murdoch <[email protected]> >> wrote: >> >> On 15/08/2012, at 11:04 PM, Luke Daley wrote: >> >>> I think we should avoid doing this. >>> >>> My issue with it is that it's weak modelling. Not to pick on FindBugs (it's >>> by far not the only plugin that does this, including my own), but what's >>> the role of a class named “FindBugsExtension”? >>> >>> These things have a purpose or function, and the name should reflect it. >>> The fact that it's a build language extension is not really relevant to its >>> name I don't think. >> >> But that's exactly it's purpose. Every plugin has an extension object that >> wires in the DSL for that plugin. It's just a container for a set of DSL >> elements for that plugin. That's all it is, the entire reason for its >> existence. Certainly, each particular element of the plugin's DSL has >> individual purpose, and should be typed and modelled and named according to >> it's purpose. No question there. >> >> The fact that the FindBugs DSL currently only contains properties that >> define some default values is a coincidence. We might later add, say, some >> ruleset definitions. These aren't defaults - they're a model. So, >> FindBugsDefaults would have to be renamed back to FindBugsExtension. >> >> These things are DSL extensions. >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
