AddParents it is then! Speaking of arguments, how do we vote on the new logo?On 2 May 2014 15:04, Ralph Goers <firstname.lastname@example.org> 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.RalphOn May 2, 2014, at 12:51 PM, Bruce Brouwer <email@example.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" <firstname.lastname@example.org> wrote:Wait a minute. Extends sounds like a great method name!On 2 May 2014 11:04, Ralph Goers <email@example.com> wrote:
I started the work on that. Should have it finished tonight.RalphOn May 2, 2014, at 6:51 AM, Gary Gregory <firstname.lastname@example.org> wrote:I think all that is needed is to rename add(M...) to addParents(M...)GaryOn Thu, May 1, 2014 at 11:37 PM, Bruce Brouwer <email@example.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 <firstname.lastname@example.org> 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@example.com> wrote:
If the API tells me the relationship, if I have to write backwards code, then I can see it is backward ;)aerr.add(err);serr.add(err);Instead I have to do:err.add(aerr);err.add(serr);Marker err = MarkerManager.getMarker("Error");But if I can make this easy mistake: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".
arker serr = MarkerManager.getMarker("SysError");
Marker aerr = MarkerManager.getMarker("AppError");
// no addChild APIserr.addParent(err);
aerr.addParent(err);And of course forget the obvious:err.addChildren(serr, aerr)so addParents(Marker...) would be OK too.GaryOn Thu, May 1, 2014 at 10:07 AM, Ralph Goers <firstname.lastname@example.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 <email@example.com> wrote:I propose to rename add(Marker) to addParent(Marker).I find the API name Marker.add(Marker) unclear.OTOH, Marker.setParents(Marker...) is clear.
And I do not want to think about addChild(Marker) ;)
Matt Sicker <firstname.lastname@example.org>
Matt Sicker <email@example.com>--
Matt Sicker <firstname.lastname@example.org>