You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the issue is that there is no method to add an associated actor. You can have more than 1, so usually there is an add... method in the API in that case. I could always just append, but I thought that wasn't the paradigm.
A while back, @gtback introduced a couple of base classes that GREATLY help in reducing the amount of code we need to write for STIX fields that have a multiplicity > 1 (i.e., lists).
However, this introduced a new pattern that deviated from the way that we had interacted with these lists in the past. Instead of something.add_foo(bar) calls, you do something.foo.append(bar). Well, we could always do the something.foo.append(bar), but now it is forced since we don't have the associated add_foo() method.
I'd like to go back through the codebase and add the def add_foo(...) methods to our classes where they are missing, just for consistency. This way, developers will be able to interact with these lists directly via the property or via the method.
Activity
[-]Need to add associated actors in ThreadActor[/-][+]Need to add associated actors in ThreatActor[/+]gtback commentedon Apr 16, 2014
@rpiazza, I believe this is already implemented:
https://github.com/STIXProject/python-stix/blob/master/stix/threat_actor/__init__.py#L69
https://github.com/STIXProject/python-stix/blob/master/stix/test/threat_actor_test.py#L55
Can you confirm that this is still needed?
rpiazza commentedon Apr 16, 2014
I think the issue is that there is no method to add an associated actor. You can have more than 1, so usually there is an add... method in the API in that case. I could always just append, but I thought that wasn't the paradigm.
bworrell commentedon Apr 17, 2014
A while back, @gtback introduced a couple of base classes that GREATLY help in reducing the amount of code we need to write for STIX fields that have a multiplicity > 1 (i.e., lists).
However, this introduced a new pattern that deviated from the way that we had interacted with these lists in the past. Instead of
something.add_foo(bar)calls, you dosomething.foo.append(bar). Well, we could always do thesomething.foo.append(bar), but now it is forced since we don't have the associatedadd_foo()method.I'd like to go back through the codebase and add the
def add_foo(...)methods to our classes where they are missing, just for consistency. This way, developers will be able to interact with these lists directly via the property or via the method.rpiazza commentedon Apr 17, 2014
So - for the near future, I should just use the append pattern?
bworrell commentedon Apr 17, 2014
@rpiazza - Yup!
gtback commentedon Apr 17, 2014
+1 for
append()😄bworrell commentedon May 2, 2014
I am going to close this out since we have a way of adding associated threat actors. Issue #117 refrs to the
add_foo()pattern.