Table API: Collection<String> is better than Collection<Strongly Typed Thing>

[rcaudy]

When we merged TableOperations, many overloads that specified Collection<String> were replaced with overloads that specified a Collection of something from the table-api library.
This is materially worse for script users from Groovy or Python, as they can no longer just pass a list that is syntactically nice from their script, but must instead write extra boilerplate.
We should consider reversing this change in November as part of the other API changes, and having the strongly-typed versions be varargs/array-oriented.

[rcaudy]

@devinrsmith @chipkent @cpwright I think you folks might be interested in contributing to this discussion.

[devinrsmith]

So - one direction we might choose to take is to introduce strongly typed Collection-specific types for all individually strongly typed things.

For example, we could define:

T aggBy(Selectables selectables, Aggregation agg);

Note: the plain Aggregation type already has a Collection-type.

[rcaudy]

I considered that, too. I think it's a good solution, and I'd be content if that's what we arrive at. Two related alternative proposals:

1. Have a single Collection-like class that we use for all of these structures. Might cut back on total code size. Then again, at that point we could just use arrays.
2. Have a "Multi" version of each structure like in Aggregation, and an "expand()" operation that gives us an array or Collection, conceivably optimizing the members/order.

@kosak is good at this kind of thing, adding him to the discussion.

[rcaudy]

I realized at some point that my proposal (2) is silly or likely implicitly part of your existing idea, @devinrsmith . I'm imagining something like:

public interface Selectables {
    Collection<? extends Selectable> collect();

    default Selectables combine(Selectables other) {
        return new Multi(collect(), other.collect());
    }
}

public interface Selectable extends Selectables {
    default Collection<? extends Selectable> collect() {
        return Collections.singletonList(this)l
    }
}

[chipkent]

I'll reserve specific comments until there seems to be a narrowing of views. Decisions in this area have an inherent tension. From the system programming side, there is a desire for very strong typing so that there are stronger guarantees that the system actually works as intended. From the script side, users just want "this simple thing" to work through magic, without thinking about typing. They live in languages that are a free-for-all, so the user overhead of strong typing is not tolerated well.

A solution that can make both sides happy is best. Some of the type loosenings could possibly happen in the script glue layer, but that increases the complexity of the glue.