> On Dec 15, 2017, at 9:41 PM, David Holmes <david.hol...@oracle.com> wrote: > >> A good litmus test: should the result contain the current class or not? If >> it does, you're giving clients a polished list of actual nest members. If it >> does not, you're just repeating to clients what the attribute says. > > The result should of course contain the current class - if it is the nest > host it is always returned as the zeroeth element.
> getNetsMembers() doesn't mean "read the Nestmember attribute of this class", > it means " get all the nest members of the nest in which this class is a > member". Okay, then my argument is that the result of 'getNestMembers' is a semantically meaningful set of classes, not just a view of the attribute contents. And under that interpretation, anomalous entries should either be silently filtered out or trigger an error. As a user, I think I'd view the method as "go find me all the classes in this nest; you may use 'NestMembers' as a hint for your search". > That conflicts with what John suggested. Sorry, John, I'd prefer different behavior. :-) Specifically: > Given the action on 4 (just let it hit the fan), I suggest that we should > also let self, outsider, and duplicate entries show through on reflection. The proposed treatment of a nonexistent class (4) is to report an error. That's fine, and maybe it makes sense to report an error in some or all of the cases. (I wouldn't object to silently ignoring the nonexistent class, though. Depends on what we think users want when a nest member class is missing—which, as we've discovered, is not uncommon.) But letting things "show through" is, I think, never what the end user will want. They will believe that anything in the array returned by 'getNestMembers' actually *is* a member of the nest. —Dan
