Rename ScheduleInfo#memo to ScheduleInfo#scheduleMemo

[mehcode]

• https://github.com/hashgraph/hedera-sdk-java/blob/main/sdk/src/main/java/com/hedera/hashgraph/sdk/AccountInfo.java#L117
• https://github.com/hashgraph/hedera-sdk-java/blob/main/sdk/src/main/java/com/hedera/hashgraph/sdk/FileInfo.java#L62
• https://github.com/hashgraph/hedera-sdk-java/blob/main/sdk/src/main/java/com/hedera/hashgraph/sdk/TopicInfo.java#L44
• https://github.com/hashgraph/hedera-sdk-java/blob/main/sdk/src/main/java/com/hedera/hashgraph/sdk/TokenInfo.java#L145
• https://github.com/hashgraph/hedera-sdk-java/blob/main/sdk/src/main/java/com/hedera/hashgraph/sdk/ScheduleInfo.java#L66

[jg-swirlds]

Given the breaking nature of renaming the field, unless there is a strong need to do it, I would recommend leaving it as-is.

[SimiHunjan]

we have done this in the past to keep consistency, but also we have a memo at the transaction level and then at the entity level. scheduleMemo makes it clear that this is the memo that this is returned from the schedule entity.

[jg-swirlds]

If we introduce a new field called scheduleMemo, and retain the existing field as memo (and deprecate it) how does this work in a non-breaking way? If users keep their existing code and continue to use the deprecated field, are they guaranteed to have the same behavior when they read / write the memo field in all the same ways that they do today?

[mehcode]

@jg-swirlds Absolutely. We have a very large deprecated surface - that only keeps increasing - largely due to Hedera itself making breaking changes. This is small potatoes in comparison.

In the specific instance we would be adding a public final String scheduleMemo field and deprecating the public final String memo field. These objects aren't constructible easily so as long as both are set from the fromProtobuf method, users should be able to continue using .memo.