New Feature Idea: wrap constructors

[kbwelker]

I thought I'd start using our group to discuss pros/cons/options of an
idea before making it an Issue on the main site.

Anyway, I was considering the option to wrap constructor calls as an
Object. The no-arg case is the simplest, and in Guava this would be a
form of a Supplier, and in Jedi it would be a form of a Functor0 (that
"0" at the end is not a typo).

I was considering something like:

Supplier<X> xS1 = supplierFor( ctor(X.class) );
Functor0<X> xS2 = functor0For( ctor(X.class) );

I'm trying to keep it terse so I chose "ctor", but perhaps that's not
as widely used as I believe and "constructor" would be better.

The above seems fairly easy and intuitive, but I need to think ahead
on how this syntax might be helpful or hurtful to expanding Funcito
capabilities in the future. For instance, do I want to support other
than no-arg ctors? I could put a varargs parameter in the ctor()
method to represent the ordered classes of the arguments. But would
the result be something folks would want to use?...

Supplier<X> xS1 =supplierFor( ctor(X.class, ArgType1.class,
ArgType2.class) );
// not too bad above, but a little smelly. But how would one use it?

X x = xS1.get()
// ! oh no, no we are not passing any values for arg1, arg2

So instead of passing arg types into ctor(), we could pass the actual
bind values:
Supplier<X> xS1 = supplierFor( ctor(X.class, 327.5, "My dog has
fleas") );

and now the xS1.get() works. But it might be a lot of trouble to
properly write all of the rules for type-coercion to ensure that we
are picking up the intended constructor. So then the question is:
would multi-args ctors be worth it, who would use it, how often, and
would the complexity outweigh the benefit?

Another perhaps simpler implementation would keep the first form I
showed, but behind the scenes I could just use Objenesis at runtime
since it's already in the jar. So Objenesis uses the no-arg ctor if
it exists, but falls back on other strategies otherwise. The
disadvantages: the user does not know what the state of the object
will be since they do no have any say in the constructor or other
technique that is used behind the scenes. Also, Objenesis is going to
make invocation of the Supplier.get() (or Functor0.execute() ) more
expensive than simply Contructor.newInstance().

So thoughts, ruminations, opinions?

[kbwelker]

Another thing this bumps into is another idea that I want to make sure
is implemented consistently with the above, I was thinking that we
could also wrap static non-void methods. The question is would they
also be Supplier/Functor0? Btw, I do not see any analog in Functional
Java. Anyway..

Supplier<X> sX =
supplierFor( staticCallsTo(SomeClass.class).myStaticMethodReturnsX() );

or since you *can* call a static on a an instance, I could use the
existing Funcito syntax:

Supplier<X> sX =
supplierFor( callsTo(SomeClass.class).myStaticMethodReturnsX() );

But in Guava, would it be beneficial to also (or instead) make a
Function<T,V> out of static calls, and if so then what would T be?

Function<Class<MyClass>,X> f1 = ...; // ???
X x = f1.apply( MyClass.class ); // does this even make sense?
Function<Void,X> f2 = ...;
X x2 = f2.apply(null);

Not sure that any of the above makes sense. I'm just pondering where
to go from here.