Using the same name in base and sdk is problematic.

[myrle-krantz]

Using the same name in base and sdk is problematic.

[bartekn]

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

I think the best way to solve this would be to add Record suffix to sdk classes. So org.stellar.sdk.Account will become org.stellar.sdk.AccountRecord. Do you have a better idea how to name it?

[myrle-krantz]

Love the quote. I'd leave the sdk.Account alone, and change the base.Account. The sdk.Account really does represent information about the account, but the base.Account represents access to an account at its current ledger number.

Hence a couple of suggestions (from most to least radical):
a.) Get rid of the base.Account, and the base.TransactionBuilderAccount, and make the transactionbuilder accept a key and a ledger number. Adjust the server to return the ledger number directly.
b.) Get rid of the base.TransactionBuilderAccount interface, and rename the base.Account class to TransactionBuilderAccount.
c.) Rename base.Account to base.TransactionAccount.
d.) Rename base.Account to base.AccountAccessKey.

That's just a handful of brainstormed ideas...

[nullstyle]

Random note: IMO, this issue here is that we're not properly shielding users of stellar-sdk from the details of stellar-base. The fact that you need to import both base.Account and sdk.Account is a design smell, to me.

I agree with @myrle-krantz that killing base.Account and base.TransactionBuilderAccount, and personally I would extend that desire to most of the helper objects in https://github.com/stellar/java-stellar-base/tree/master/src/main/java/org/stellar/base. The fact that we have a bunch of helper objects to make it easier to work with memos is indicative, in my opinion, of a poor API.

The motivation for these helper classes that "shadow" the XDR structures is, I believe, to make it easier to work with building the XDR that is required by the stellar protocol. We then further wrap the new "helper" classes in a builder pattern, to ostensibly make it easier to construct the helper objects. This is a mistake IMO: The builder objects that stellar-base exposes should instead directly work upon the xdr objects.

Let me instead propose an alternate "story" of interacting with the stellar network through java-stellar-sdk. I don't think we have a strong vision of what it should be like to use this library, and I think we would be well served by having one.

First, lets divide the experience into two halves: "reading and interacting with data from horizon" for one of the halves, and the other half will be "authoring new transactions for inclusion" into the network. IMO, most integrating will begin with reading from or responding to events from horizon, and so most of the classes we expose should aid in that endeavor. We should provide well-defined paths into the authoring experience of the library that hangs from the reading side.

I've written some psuedo-code that illustrates some of my ideas here: https://gist.github.com/nullstyle/db1e5742819b7eb3f5f9

Some takeaways from the sample:

1. We don't need to import classes from java-stellar-base.
2. The objects involved provide methods to continue communication with the server. Note that SubmissionSuccessResponse has a method getTransaction() that loads more data from horizon
3. Some of the overloads in the payment builder have inputs that are symmetric to the outputs of the read API. For example, getFrom() returns a String and so one of the overloads of destination takes a String, instead of being restricited to a stellar-base KeyPair

---

In standup today bartek made the case for merging java-stellar-base and java-stellar-sdk. I'm not opposed to this. These ideas are just one potential direction, and I'm open to others. I'd bet that you have more experience than either bartek or I when it comes to designing java APIs, so I would love your input. There's an opportunity here to heavily influence the API, if you're interested in helping us.

[myrle-krantz]

I too would tend toward merging base and sdk as Bartek suggests.

I like your pseudo-code, Scott, and your use of streams and lambdas is elegant. I would be a little nervous about the client-side filtering of potentially large amounts of data there, but I'm guessing you all have a better understanding of the amount of data involved than I do, and that part's not central to your case.

I disagree that authoring new transactions is secondary. It's the first thing I'll be doing after creating an account (oh wait: I guess that does make it the second thing I'll be doing: o).

But none of this actually solves the problem that you've run into here: you really do have two account objects: one which represents the address of an account and one which represents the data contained in it as retrieved from the server. This probably isn't the only place you'll have this duality either. Transaction looks like another candidate. I wouldn't mix these two separate concerns into all-purpose objects, though I would make it as easy as possible to move from one to the other. (As you intimate, Scott) I would try to create a naming standard which makes it clear which object is on which side of that divide.
For example: AccountAddress, and TransactionAddress vs. Account and Transaction, or AccountId and TransactionId vs AccountRecord and TransactionRecord. Then I'd use the server to go from AccountId to AccountRecord (using one set of names here as an example), and use a factory function to go from AccountRecord to AccountId.

I do love APIs, but getting involved in the naming discussion does feel a bit like inserting my two cents into a marital conflict. I'm happy to make suggestions, but the final decision belongs to you all.

[bartekn]

java-stellar-base and java-stellar-sdk merged.

[myrle-krantz]

Thank you