Java generic foundations library

[juan_gandhi]

These are notes for an abstract for a future article; comments are invited, but please note that I'll be changing the text

There is a lot of data management knowledge in databases that is kind of skipped by "regular" programmers. E.g. joins, unions. Well, maybe join, which is, mathematically speaking, a pullback, is not needed in all its generality (I'd rather discuss it separately) - but how about simple operations, like map composition, map reversal, getting an image of a collection via a map?

Actually, what we need is not even a map. Let's start with class Function<X,Y> that has just one method, Y apply(X x). A special case of Function is Filter<X>, which is just Function<X,Boolean>, with a method boolean filter(X x) that is a synonym to Boolean apply(X x). Filter is actually a predicate, but, well, predicates seem to be too much for an average programmer.

So, if we have a Map<X,Y> map, we can define Function<X,Y> function(Map<X,Y> map) as something that returns values for keys. And, on the other hand, if we have a Function<X,Y> function, we can define Map<X,Y> map(Function<X,Y> f, Set<X> domain) as a virtual (no actual data structures created) map that maps X x from Set<X> domain to Y f.apply(x).

Having a function definition, it is easy to define composition of two functions; a composition of maps is a virtual map that derives from their corresponding functions composition.

There are two ways to revert a function f: X -> Y - one, if a function is isomorphic, then it has an inverse g: Y -> X; another is defined as g: Y -> Set<X>; for a Y y it returns {X x | y.equals(f(x))}.

Functions can be applied to Sets, Collections, Lists, Iterables.

Using Java 5 vararg, we can define join for Collections, Lists and Iterables:

Collection<T> join(Collection<T>... elements) - e.g.

Collection<String> join(Arrays.asList("abc", "def", "gh"), Arrays.asList("x", "y", "z")) is a virtual Collection (no data moved around, no new structures created) that contains all the Strings listed above.

There are currently problems with type inference when passing varargs of abstract types - but this seems to me rather a current Java compiler bug (see http://www.daimi.au.dk/~pahe/peter-ahe-thesis.pdf and http://www.daimi.au.dk/~pahe/peter-ahe-thesis.pdf re: "unchecked generic array
creation") than a real issue. Under investigation, though. Hints and ideas welcome.

Comments

оч любопытно

[exceeder.livejournal.com]

и достаточно элегантно. Слово "достаточно" можно, пожалуй, опустить :)

"predicates seem to be too much for an average programmer" - ну это я тоже с большим удивлением обнаружил на практике, введя их в мой доморщеный аналог EJB QL :)

Интуитивно кажется, что тут больше зарыто. Надо дальше додумывать. Не хватает только опыта с "Тигром" - некогда... :(

Re: оч любопытно

[ivan-gandhi.livejournal.com]

Вот я и чувствую, что эти просторы раскрываются как-то вдруг, как только начинаешь в это дело вникать.

Например, я пробовал было всунуть функторы (и даже сопряжённые), классификатор подобъектов... или, наоборот, попробовать интуиционистскую логику ввести в качестве параметра - но очень тяжело бороться с повсеместным торжеством Boolean. Плюс, народ не поймёт.

А кванторы... Ну да ладно.