Closed ramontayag closed 6 years ago
@nullstyle what do you think of this? When working on a high-level convenience method for change_trust
, I realized there'd be less logic there about the value of the attribute if Stellar::Operation.change_trust
knew how to handle nil limits.
@ramontayag I'm hesitant to merge this. Stellar base is a low-level library, and setting a trustline to the max by default is a client-focused, high-level choice. We pick a default for the limit in part because we don't want end users (or other non-technical participants) to burden themselves with the notion of a trustline limit until they need to know it.
Developers, however, should IMO understand that every trustline has a limit and they should probably be deciding directly what appetite for counter party risk their software can tolerate. Having no default on this method is one mechanism for that.
Care to make a counter case? I'm open to be convinced that it provides more help than harm.
@nullstyle what you said makes sense. This can be handled in ruby-stellar-sdk instead! Thanks.
Useful when there's a wrapper code that always passes this key, regardless of the value being
nil
.