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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
