Re:Why Go and Not Rust?
by sytringy05 on Monday September 16, 2019 @08:57PM
(#20990130)
It definitely is common with generics, it happens all the time. Here's some production code I've worked on recently:
new TypeReference<FooResponseCollectionResource<MemberUpdate>>(){})
Many languages do support type alias. In C# you would do
using NiceType = TypeReference<FooResponseCollectionResource<MemberUpdate>>
// ....
new NiceType ()My point was that the commonly mocked VisitorObserverFacadeFactoryFactory Java idiom doesn't normally use generics at all.
Of course you can mix generics with terribly named classes and OOP patterns, but that's hardly a problem with generics themselves.
what's the alternative ? using an "untyped" variable ?
but then you loose type checking and some people don't like to loose type checking...
Re:Why Go and Not Rust?
by KptMarchewa on Tuesday September 17, 2019 @07:46AM
(#20993842)
Do not use patterns that require you to write code like that.
You never have cases where you have a list of lists? Or do you introduce a pointless wrapper type for the inner lists to "hide" the generics?
That's the answer for me.
The problem in those cases always the abuse of often obsolete OOP patterns and misnamed classes.
Or use type aliases that are helpful.
> I'm sorry, this is a terrible argument. That's definitely not a common usage of Generics.
It is very common indeed in the three large Enterprise Java houses I've worked in over the past 15 years. FizzBuzzEnterpriseEdition is the reality in all three of those places. Not only is it reality, it is requirement.
I'm sorry, this is a terrible argument. That's definitely not a common usage of Generics.
The common enterprise OOP idiom that is mocked is NaturalNumbersFacadeFactoryFactory, which use no Generics at all, leading to a large number of classes.
Ironically, if one used generics to replace factories like you did in your example, you would be able to replace hundreds or thousands of Factory or FactoryFactory classes in an enterprise application with a single Factory<T> class. Of course, that would probably be pointless. There's a reason multiple factories exist in a program, even though there are ways to replace them with something simpler.
I get it that Go programmers don't want the language to be complex, but Generics themselves don't have to be complex. They solve a lot of problems in a simple way and are MUCH easier to use than ad-hoc generics made using interface{} + Reflection.