There are 3 conceptual spaces which exist both inside and outside the AVM (that is, the user's code directly sees the external perspective but is mapped to use the internal perspective, on deployment):
JCL -> Shadow JCL
User code -> Transformed user code
API -> API
The API is the strange case in that its classes are not renamed into a shadow namespace but this causes confusion which shouldn't exist:
Tests can only instantiate Address within the context of an attached thread - if there was a more explicit "external" variant, it would just be a normal object
ABIEncode has both internal and external method implementations in the internal implementation, whereas these pieces of logic should live in their respective areas
Safe embedding of the external variants isn't possible since they don't typically have sufficient implementation
There are 3 conceptual spaces which exist both inside and outside the AVM (that is, the user's code directly sees the external perspective but is mapped to use the internal perspective, on deployment):
The API is the strange case in that its classes are not renamed into a shadow namespace but this causes confusion which shouldn't exist:
Addresswithin the context of an attached thread - if there was a more explicit "external" variant, it would just be a normal objectABIEncodehas both internal and external method implementations in the internal implementation, whereas these pieces of logic should live in their respective areas