> > 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. >
You're right. What I meant is I'd rather model from the build, where the internal implementation name has little impact. > 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 > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
