If you have time can you see how to do a vote with Apache Steve?  That is the tool the ASF uses to vote on the board of directors and new members. 


On May 2, 2014, at 1:30 PM, Matt Sicker <boards@gmail.com> wrote:

AddParents it is then! Speaking of arguments, how do we vote on the new logo?

On 2 May 2014 15:04, Ralph Goers <ralph.goers@dslextreme.com> wrote:
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.


On May 2, 2014, at 12:51 PM, Bruce Brouwer <bruce.brouwer@gmail.com> 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" <boards@gmail.com> wrote:
Wait a minute. Extends sounds like a great method name!

On 2 May 2014 11:04, Ralph Goers <ralph.goers@dslextreme.com> wrote:
I started the work on that.  Should have it finished tonight.


On May 2, 2014, at 6:51 AM, Gary Gregory <garydgregory@gmail.com> wrote:

I think all that is needed is to rename add(M...) to addParents(M...)


On Thu, May 1, 2014 at 11:37 PM, Bruce Brouwer <bruce.brouwer@gmail.com> 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 <boards@gmail.com> 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 <garydgregory@gmail.com> 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");

Instead I have to do:


If the API tells me the relationship, if I have to write backwards code, then I can see it is backward ;)

// no addChild API

And of course forget the obvious:

err.addChildren(serr, aerr)

so addParents(Marker...) would be OK too.


On Thu, May 1, 2014 at 10:07 AM, Ralph Goers <rgoers@apache.org> 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.


On May 1, 2014, at 6:57 AM, Gary Gregory <garydgregory@gmail.com> 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) ;)



Matt Sicker <boards@gmail.com>


Bruce Brouwer


Matt Sicker <boards@gmail.com>

Matt Sicker <boards@gmail.com>