Naming nodes about npbehave HOT 7 OPEN

Update: I found out you can "Label" nodes. What about adding extension method or member method to node like

new Selector(...).Labeled("Steering");

or "fake decorator" like

NPBehave.Labeled("Steering", new Selector(...));

Probably best solution would be to add this directly in the constructor like so

new Selector("Steering", ...);

But that would require a lot of changes

from npbehave.

Hey, so the intended syntax for the labelling is quite similar to your first idea
new Selector(...).Labeled("Steering");

it goes like this:

new Selector(
...
 ) { Label = "Follow" }

adding your idea wouldn't be much work, but maybe you can work already with the syntax we have?

from npbehave.

Checked it briefly, it's fine but "Fake Decorator" would be still a little better due to information flow. Because then you have label next to actual node definition and not after this.
This could be added as a simple Utility Method, I might try doing it later.

from npbehave.

OK. We can maybe also go for the one to include it in the constructor, but it will increase amount of mandatory fields. I would like to keep it optional if possible...

With 2.0 I'll probably have to rethink the way we handle growing amounts of fields in the constructors. Not sure if there is any better way to describe the trees by Code. But I would like to also reduce the amount of constructors if possible.

Maybe we could prefer using named parameters somehow, but I'm not sure if it works with the composites so well. Maybe we could live with something like

new Selector( label: "Follow", children: [
...
] ),

from npbehave.

Actual utility method would look more or less like this now that I look at it:

public static class NPBehaveUtils
{
  public static Node Label(string label, Node node)
  {
    node.Label = label;
    return node;
  }
}

Now, you can just add using static NPBehaveUtils on top of the script and done

Label("Steering", new Selector(
  ...
));

from npbehave.

I also think, after second thought that it would be the best solution due to it being universal for every Node

from npbehave.

right. Let's keep it simple for now. For 2.0 we can rethink this

from npbehave.