The same problem was discovered 15 years ago in Java :)
The first attempt to fix it was to use dynamically generated proxies.
The IAdaptable mechanism proposed by Ken Beck is an example of that for Eclipse [1].
This was ultimately fixed by introducing default methods which is as restricted way of implementing Traits [2] in Java 8.
I guess Go will have to follow a similar direction.
> The same problem was discovered 15 years ago in Java :)
I swear go is different and doesn't need to learn from mistakes from other languages, because after all, you don't need that with go…
Instead of being arrogant maybe go designers should have listened to the people who told them 10 years ago that these issues were real, and not a product of "bad coding practices". Because this:
> . The Prometheus people try hard to do it anyway, and the result is rather messy and involves a combinatorial explosion of the possible combinations of APIs.
Go has benefitted immensely from not starting out looking like Java from day 1. No one doubts that these edge cases come up from time to time, but how can Go know which features of Java exist because of hard-won experience and which aren’t? Further, even when there is a use case for a given feature, that use case is often marginal and the feature people want would impose on every other use case—in such a case, it’s often better to drop the feature, and Go has profited tremendously in this regard. But yeah, sometimes it misses some features that Java has and it has to add them back in, and the Java people think it’s cause to dunk on Go, but Go is still profiting from all of the misfeatures that are in Java but not in Go. Anyway, people make far too big a deal about things like type checking (if a language is statically typed at all, that’s 95% better than dynamically typed languages and everything else is just bickering about the additional 5%) and other language features and consistently undervalue tooling, static linkage, ecosystem, learning curve, and simplicity.
Go didn’t get everything right, but I’m happy it’s not Java.
The comparison was between Go and Java circa 2012 when ago was first released. Not between 2012 Go and 1995 Java. Notably, Go has things like closures and implicit interfaces which make it much easier to write more abstract code than pre-generics Java (which depended heavily on downcasting).
I’m not sure if generics will be a net benefit to Go. I often wish I had them, but I rarely need them to make code type safe. Further, I don’t think Go will be able to retain its property that solutions implemented in ago tend to be flat-footed/boring/not-overly-abstract nor the property that different developers tend to approach similar problems in very similar ways (I.e., Go tends to be written in very standard ways). Of course, if you’ve never used Go for a considerable time, you will likely devalue these properties, but they turn out to be really useful, especially in a collaborative setting. Maybe they won’t be lost when generics arrive, or maybe generics will be a net positive. I hope so, but I’m concerned. I think Go is quite a lot nicer to read and write than other languages with generics, and I would be sad if it backslid.
Right... for people who don't know, QueryInterface was the fundamental method client code would call on a COM object to get a particular interface.
The key here, is the object can implement this any way it wants.
A typical "static" object would just return itself as the requested interface for the interfaces it supported. But a proxy object, with a wrapped upstream object, could pass through requests for interfaces it didn't know or need to override to the upstream object.
I don't know Go, but a quick google makes me think type assertion is the mechanism for getting an interface from an object at runtime. So if Go allowed a type to override type assertion, I think that should enable middleware and other proxy objects to behave well.
AFAIK with package `reflect` it is not possible to attach methods to a dynamically create type. And that seems to be a prerequisite to be able to generate dynamic proxies at runtime.
Java can modify bytecodes since the JVM ClassLoader is a first class construct in Java. Using distinct ClassLoader roots, one can have multiple diverse versions of the same canonical ‘type name’ (e.g. foo.bar.paz.MyList) at the same time in the same running process.
The first attempt to fix it was to use dynamically generated proxies. The IAdaptable mechanism proposed by Ken Beck is an example of that for Eclipse [1].
This was ultimately fixed by introducing default methods which is as restricted way of implementing Traits [2] in Java 8.
I guess Go will have to follow a similar direction.
[1] https://wiki.eclipse.org/FAQ_How_do_I_use_IAdaptable_and_IAd...
[2] https://en.wikipedia.org/wiki/Trait_(computer_programming)