Learning typeclasses

[davidrpugh]

Exploring ad-hoc polymorphism and type classes as a solution to some typing problems.

[bherd-rb]

@davidrpugh Interesting, I'm also reading about typeclasses and scalaz at the moment. What are you trying to achieve in this PR?

[davidrpugh]

Apparently structural or duck-typing is quite inefficient (as it requires using reflection) and should generally be avoided. Going forward it is probably a good idea to sort out a solution that avoids using this feature. Codacy results discuss this an provide references...

[davidrpugh]

Major objective with this PR is to solve issues related to the return types of the insert, remove, clear methods. Currently the code in the develop branch does not return the correct sub-type of auction when trying to implement auctions with various quoting policies.

Once could create an auction with a particular quoting policy without issue, but then if you insert an order into the auction you get back the wrong auction type! You will get a more general auction type that no longer has a quoting policy! This PR uses type-classes and ad-hoc polymorphism to solve this problem.

[davidrpugh]

@bherd-rb If you are interested in Scalaz I would recommend taking a look at TypeLevel and cats as well as all of the rest of the Typelevel projects.

[davidrpugh]

@bherd-rb I am having trouble getting Java to find the implicitly defined methods on the auction instances. I thought that since Scala is compiled before Java, the Java compiler would have access to the compiler generated methods. I guess not?

[bherd-rb]

@davidrpugh I have to admit that I haven't really got my head around implicits in Scala yet. They are still a mystery to me. I'll have to do some reading and try to figure out what the problem could be.

Thanks also for the pointers to TypeLevel and cast. I'll take a look.

[davidrpugh]

@bherd-rb After using javap to examine the Java byte code it appears that the Scala compiler weaves together the various components of the type class and creates an anonymous class. For example the UniformPricingImpl of the SealedBidDoubleAuction type class is compiled down into the SealedBidDoubleAuction$UniformPricingImpl$$anon$2.class file. Apply javap to this file shows that the relevant methods are defined inside a public final class of the same name.

In principle it seems like it should be possible to somehow create an instance of this class, but I have not yet worked out how...

[davidrpugh]

@bherd-rb Take a look at the Sandbox.java file. I managed to sort out a solution that involves manually "weaving" the Ops class and the UniformPricingImpl class together. Perhaps this logic could be encapsulated inside a JSealedBidDoubleAuction class?

Still not convinced that this is the only solution...

[davidrpugh]

@bherd-rb For reference here is the discussion I started on SO.

[davidrpugh]

@bherd-rb I just made a first attempt at creating a Java wrapper JSealedBidAuction.java for the new Scala type class of similar name. There is an example use case in the Sandbox.java file. What do you think? I am not a confident Java programmer so might be a bit of a hack job :)

[davidrpugh]

@bherd-rb I have added an open-bid, double auction with discriminatory pricing to the Java functional sources. Take a look and tell me what you think. If this works for you, then I propose that we move the java implementations of the auctions into the core library code, quickly add the remaining auctions, tidy everything up, and merge...

[davidrpugh]

@bherd-rb I went ahead and added Java wrappers for most of the remaining auction types. I haven't yet implemented Java equivalents for the various companion object methods such as withAskQuotePricingPolicy. I am not sure that we need to bother with these convenience methods at present. Thoughts?

[bherd-rb]

@davidrpugh Sorry for the delay, I'm quite busy at the moment. I'll take a look at the implementation.

[davidrpugh]

@bherd-rb No worries I am going to work on other things for a bit. I just want to make sure that you have a working Java implementation that serves your purposes for the first release. We can optimize things later...

[bherd-rb]

@davidrpugh I've just updated my code and integrated the new wrappers. Great stuff! It's a bit annoying to write and maintain all these separate wrapper classes in ESL but from a Java perspective, it's clearly much more user-friendly now.

We definitely have to switch to Scala as soon as possible in our code ...

[davidrpugh]

@bherd-rb Great! It is a bit annoying, but I probably spent 10x less time writing the wrapper classes in Java then I spent understanding the intricacies of the Scala compiler generated byte code. I need to add implementations for double auctions with uniform pricing. Given that you are happy with the work thus far I am going to do this now and then start cleaning things up in preparation for our first release.

[davidrpugh]

@bherd-rb One other thing I want to do is to push the conversion from Scala Stream into the clear method of the various Java wrappers. Do you have a preference for the Java type? Should I try to keep everything lazy and convert Scala Stream to Java equivalent? Or just convert to a List?

[davidrpugh]

@bherd-rb I just added a JClearResult wrapper that encapsulates the conversion process between a Scala Stream and a Java Stream. Does this work for you? I thought preserving the laziness of the pipeline on the Java side was worthwhile in the near term for consistency with the Scala API. Going forward I am not convinced that a Stream is really the right type of collection to store the fills but I think we need to experiment more before making this choice...

[davidrpugh]

@bherd-rb Take one last look and let me know if you see anything amiss. Not that now Java auction wrappers make use of a JClearResult which represents fills using a Java Stream. If all looks good to you I am going to merge to develop...

[bherd-rb]

@davidrpugh The new version including JClearResultworks very well! I'm going to approve the changes so that you can merge everything.