@cedric: It is just list of libraries. Without categories and other useful information (as in the link)

@nihisil: usually one googles github, finds a lib, then gets its maven credentials and ide (or gradle) adds them to the project

So, there is no service like this one https://www.djangopackages.com/grids/g/authorization/

but for Java

I had to go with usual way, google the libraries, check them on github and etc. by hands

well, the link you gave lists modules for a framework, not python libraries

so I guess there are lists of modules for java frameworks too

depending on a framework

not sure why would one use such a list, since you probably want to know much more information that on this site anyway

It is true simple smile Just wanted to confirm it, maybe there is the place like this and I just wasn’t able to find it simple smile

there isn't one for python , is there ?

yep, for python we have only the list of libraries, like maven has

@nihisil: came to mind https://github.com/akullpp/awesome-java

It’s the same for all languages

or just being able to store data and know at compile-time that what you're storing and retrieving is of the type you're asserting it is? How does Scala help you get around this?

There’s no nice way to express

fun toUser(jsonText: String) : User

Certainly no type safe way to express it. It’s by very definition a runtime operation.

i.e. it has to be

fun toUser(jsonText: String): User?

(or

Optional<User>

or whatever)

When you have a system of generics that have to be constructed for this materialized type, how do you go about that?

A set of objects based on that generic type. Rule<X>, RuleEvaluation<X, Value>, etc.

X is still unknown throughout the generic materialization code.

When you deal with families of generic types, type erasure lets you down, fast.

And reification makes you second guess the type system

this is an argument against erasure/jvm in general rather than java the language...

If you have to ask a collection the type of its elements, you’ve already lost.

Yep. But understand that erasure is usually where the type system stops behaving as expected, because code that seems natural and intuitive to the writer simply doesn't work.

I don’t see how, erasure forces you to remain confined in the safe world that the compiler has validated for you. Go out of these boundaries at your own risk.

And the point of the above was to say that Rule<X> and RuleEvaluation<X, Value> don't need to know what X is specifically, but they still want to be internally consistent - knowing that X is a specific type and that it is handed associated objects that also work with the correct type.

I want to know that a RuleEvaluation<String, String> can be validly handed to a Rule<String> but not a Rule<Int>

If the type info isn't available, the benefits of generics and the type system evaporate.