I would be in favor of renaming .add(Marker parent) to .addParents(Marker... parents). If people think it's a big deal, we could have .addParent(Marker parent) and .addParents(Marker... parents), but I don't see a lot of value in having two methods.
It is true, I do really want to have the vararg version. We could go crazy and rename .setParents(Marker... parents) to .extends(Marker... markers) and .add(Marker parent) to .andExtends(Marker... markers). That would go along with the interface nomenclature used of .isInstanceOf(Marker marker) On Thu, May 1, 2014 at 4:16 PM, Matt Sicker <[email protected]> wrote: > So it seems like using the word "add" in this context sort of implies > adding a child or contained marker when it actually does the opposite. A > word like "with" or "from" or "using" might make more sense if we wanted to > keep the single word method name idea. Otherwise, addParent[s] or parent[s] > might work, too. > > And in regards to the logo, what's the next step? Run-off voting on the > remaining candidates? > > > On 1 May 2014 09:25, Gary Gregory <[email protected]> wrote: > >> Well, a hierarchy has has node that are parents and children. >> >> Our docs say: >> >> /** >> * Markers are objects that are used to add easily filterable >> information to log messages. >> * >> * Markers can be hierarchical - each Marker may have a parent. This >> allows for broad categories >> * being subdivided into more specific categories. An example might be a >> Marker named "Error" with >> * children named "SystemError" and "ApplicationError". >> */ >> >> >> But if I can make this easy mistake: >> >> Marker err = MarkerManager.getMarker("Error"); >> arker serr = MarkerManager.getMarker("SysError"); >> Marker aerr = MarkerManager.getMarker("AppError"); >> err.add(serr); >> err.add(aerr); >> >> Instead I have to do: >> >> serr.add(err); >> aerr.add(err); >> >> If the API tells me the relationship, if I have to write backwards code, >> then I can see it is backward ;) >> >> // no addChild API >> serr.addParent(err); >> aerr.addParent(err); >> >> And of course forget the obvious: >> >> err.addChildren(serr, aerr) >> >> so addParents(Marker...) would be OK too. >> >> Gary >> >> >> >> >> On Thu, May 1, 2014 at 10:07 AM, Ralph Goers <[email protected]> wrote: >> >>> Well, Bruce wants that method to accept a variable number of Markers, so >>> a name that is singular would be awkward. What else would one be adding? >>> >>> It seems like we spend more time discussing renames than anything else - >>> like actually picking a logo. >>> >>> Ralph >>> >>> On May 1, 2014, at 6:57 AM, Gary Gregory <[email protected]> wrote: >>> >>> I find the API name Marker.add(Marker) unclear. >>> >>> OTOH, Marker.setParents(Marker...) is clear. >>> >>> I propose to rename add(Marker) to addParent(Marker). >>> >>> And I do not want to think about addChild(Marker) ;) >>> >>> Gary >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second >>> Edition<http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Matt Sicker <[email protected]> > -- Bruce Brouwer
