Re:Forget monoliths vs. microservices: cognitive load is wha...
by jerf on Friday June 21, 2019 @10:02AM
(#20242559)
Thank you for the example.
"Mind explaining the advantage of auto-generating interfaces for library usage over shims?"
For the particular definition of "shim" used by Microsoft, the fact that it's always implicitly there, rather than something you have to generate and add to the code. For example, if you import the "strings" library and use only "TrimSpace" and "IndexOf", there would be a way to A: have the tooling system directly feed you a listing of "this is what you use from this library/object/etc.", possibly even pregenerating the manifested interface and an initial stub object for you and B: there's a way to coordinate passing your new interface as the implementation of the "string library" that is going to be used for a particular run time context. The compiler can also statically test that your implementation completely covers the module; if you add a call to string.ToLower(), the compiler can complain that your shim is now incomplete.
For static usage, I expect to say that the common use case is that you use the default implementation of the strings library, and in that case, it can be statically compiled as usual. I observe that in practice there's almost always a "real" implementation that is used everywhere except tests. If you're willing to pay the price for dynamic resolution, you'd be able swap out whatever you like during runtime though.
In the common case, I expect it would look a lot like what a modern language does; you say "import string" (somehow), and you just get on with using the string functions. If you don't want to override that, you don't see anything strange.
Languages that already have some similar features would include Python, where a module comes in to your namespace as just another object. In Python it's pretty easy to "duck type" up something that looks enough like a module that you could replace one if you want. I don't see it done often, probably because it's a global variable modification, but it's an example of how you can conceive of a library or module as something other than a completely static import of a static name.
(Hypothetically, you could even get some dynamic overrides to be compiled statically in some cases. There are languages like Rust that successfully do that sort of thing a lot. However, that has a lot of preconditions for it to work, and requires a great deal of sophistication in the compiler. Initially I'd punt; performance is not my #1 goal, and if the implementation just fell back to dynamic resolution it wouldn't be the end of the world. Plenty of languages do just fine with having vtables.)
"Mind explaining the advantage of auto-generating interfaces for library usage over shims?"
For the particular definition of "shim" used by Microsoft, the fact that it's always implicitly there, rather than something you have to generate and add to the code. For example, if you import the "strings" library and use only "TrimSpace" and "IndexOf", there would be a way to A: have the tooling system directly feed you a listing of "this is what you use from this library/object/etc.", possibly even pregenerating the manifested interface and an initial stub object for you and B: there's a way to coordinate passing your new interface as the implementation of the "string library" that is going to be used for a particular run time context. The compiler can also statically test that your implementation completely covers the module; if you add a call to string.ToLower(), the compiler can complain that your shim is now incomplete.
For static usage, I expect to say that the common use case is that you use the default implementation of the strings library, and in that case, it can be statically compiled as usual. I observe that in practice there's almost always a "real" implementation that is used everywhere except tests. If you're willing to pay the price for dynamic resolution, you'd be able swap out whatever you like during runtime though.
In the common case, I expect it would look a lot like what a modern language does; you say "import string" (somehow), and you just get on with using the string functions. If you don't want to override that, you don't see anything strange.
Languages that already have some similar features would include Python, where a module comes in to your namespace as just another object. In Python it's pretty easy to "duck type" up something that looks enough like a module that you could replace one if you want. I don't see it done often, probably because it's a global variable modification, but it's an example of how you can conceive of a library or module as something other than a completely static import of a static name.
(Hypothetically, you could even get some dynamic overrides to be compiled statically in some cases. There are languages like Rust that successfully do that sort of thing a lot. However, that has a lot of preconditions for it to work, and requires a great deal of sophistication in the compiler. Initially I'd punt; performance is not my #1 goal, and if the implementation just fell back to dynamic resolution it wouldn't be the end of the world. Plenty of languages do just fine with having vtables.)