I realized that after I sent that that we cannot call the method extends(...) as it is a reserved word. We could call it setExtends(...) and addExtends(...).
My first vote is for set/addExtends(...). My second choice is set/addParents(...). On May 2, 2014 3:16 PM, "Matt Sicker" <[email protected]> wrote: > Wait a minute. Extends sounds like a great method name! > > > On 2 May 2014 11:04, Ralph Goers <[email protected]> wrote: > >> I started the work on that. Should have it finished tonight. >> >> Ralph >> >> On May 2, 2014, at 6:51 AM, Gary Gregory <[email protected]> wrote: >> >> I think all that is needed is to rename add(M...) to addParents(M...) >> >> Gary >> >> >> On Thu, May 1, 2014 at 11:37 PM, Bruce Brouwer >> <[email protected]>wrote: >> >>> 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 >>> >> >> >> >> -- >> 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]> >
