Closed amsan7 closed 6 years ago
I think both of these behaviors were intentional choices. The thought was that the function is supposed to give you back everyone who interacts with that child. And if you put in "Adam" but there are multiple Adams, that's probably something you didn't realize and we should tell you. To get that child, you need a corpus as well.
But maybe this isn't the right behavior?
Right, that makes sense (and is the case for other functions as well). There should definitely be some behavior somewhere that allows you to get all participants who interact with a given child. I'm just thinking that when I run get_tokens(child="Shem", token="run")
, do I expect to get "run" tokens from just that child or all participants connected to that child? The way the function is written, I think I expect the former, but this could maybe be cleared up with documentation.
what about all_participants
argument? then it could be TRUE
by default to return parent tokens as well?
we could add get_child_tokens
which aliases get_tokens(..., all_participants = FALSE)
- is this too heavy weight?
get_tokens
should have target_child
rather than child
as argument.
consensus is yes on all these changes
I renamed child
to target_child
in all the relevant functions, which makes clearer what they're returning. The all_participants
argument doesn't really make sense because it would be redundant with role
and role_exclude
.
I'm not really expecting all participants related to a child to be returned when I enter a name for the
child
param (but that is the case). Also, I can't search for a child that shares a name with other children (e.g. "Adam") - I get this error:Duplicate or missing child