What is an “Extends”?  I’m implementing addParents.  I’m getting tired of 
“arguments” about names. I’m still having trouble figuring out what a 
LoggerProvider is if it isn’t a Factory and is, in fact, a Logger.

Ralph

On May 2, 2014, at 12:51 PM, Bruce Brouwer <[email protected]> wrote:

> 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
>>> 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
> 
> 
> 
> 
> -- 
> Matt Sicker <[email protected]>

Reply via email to