Change SoyValue to be an abstract base class instead of an interface.
Merge many Abstract* classes into their interfaces which have now been made abstract. Mark as many methods final as possible.
The goal here is to:
Improve method dispatch performance, invokevirtual is easier than invokeinterface for the VM and final methods are even easier to reason about (but you cannot mark interface methods final)
simplify the type hierarchies by simply reducing the number of classes.
e.g. we don't need SoyListAbstractSoyList and ListBackedList we can get away with just SoyList 🎉
The trickiest part of this is the multiple inheritance in the collection hierarchies. Before we had SoyMapSoyRecord and SoyLegacyObjectMap as parallel interfaces. Many of the implementations like DictImpl or SoyMapData implemented all 3, some like SoyMapImpl or SoyRecordImpl implemented only 1. To fit everything into the singly-rooted hierarchy we had to pick a hierarchy across these 3. I decided on....
The reason I selected this relationship was due to prior art for SoyProtoValue, and this also seemed to be mostly compatible with the Js object system. if SoyLegacyObjectMap is just Object<string,?> then SoyRecord is some concrete struct (which can always be upcast to object), and SoyMap is an es2015 Map which is a very special kind of object.
The main alternative I considered was changing many methods to be static. This is a much larger breaking change, and at least my attempt ended up being a regression. AFAICT, The reason why is because static -> virtual -> static is worse than virtual -> static. So the only really good usecase for making things static is if they don't need to call a virtual method, if they do then we are inhibiting the JITs ability to understand that virtual call. Making a method final is just as valuable and far more compatible so this approach ends up being simpler.
Changing the type hierachy is risky, so i spent some time auditing various instanceof tests on the SoyLegacyObjectMap and SoyRecord interfaces to see if there might be latent issues and these are thankfully quite rare and seem fine.
Change SoyValue to be an
abstractbase class instead of aninterface.Merge many
Abstract*classes into their interfaces which have now been madeabstract. Mark as many methodsfinalas possible.The goal here is to:
invokevirtualis easier thaninvokeinterfacefor the VM andfinalmethods are even easier to reason about (but you cannot markinterfacemethodsfinal)SoyListAbstractSoyListandListBackedListwe can get away with justSoyList🎉The trickiest part of this is the multiple inheritance in the collection hierarchies. Before we had
SoyMapSoyRecordandSoyLegacyObjectMapas parallel interfaces. Many of the implementations likeDictImplorSoyMapDataimplemented all 3, some likeSoyMapImplorSoyRecordImplimplemented only 1. To fit everything into the singly-rooted hierarchy we had to pick a hierarchy across these 3. I decided on....SoyMapextendsSoyRecordextendsSoyLegacyObjectMapThe reason I selected this relationship was due to prior art for
SoyProtoValue, and this also seemed to be mostly compatible with the Js object system. ifSoyLegacyObjectMapis justObject<string,?>thenSoyRecordis some concrete struct (which can always be upcast to object), andSoyMapis an es2015Mapwhich is a very special kind of object.The main alternative I considered was changing many methods to be
static. This is a much larger breaking change, and at least my attempt ended up being a regression. AFAICT, The reason why is becausestatic->virtual->staticis worse thanvirtual->static. So the only really good usecase for making thingsstaticis if they don't need to call avirtualmethod, if they do then we are inhibiting the JITs ability to understand that virtual call. Making a methodfinalis just as valuable and far more compatible so this approach ends up being simpler.Changing the type hierachy is risky, so i spent some time auditing various
instanceoftests on theSoyLegacyObjectMapandSoyRecordinterfaces to see if there might be latent issues and these are thankfully quite rare and seem fine.