Provide proxy interface as well as Supplier for let and junitMixin

[ashleyfrieze]

Where it's possible, it would be a brilliant bit of syntactic sugar to be able to replace

Supplier<MyThing> myThing = let(() -> new MyThing());

// in test code
Foo foo = myThing.get().getMyProperty();

with something where there's less indirection - say:

MyThingInterface myThing = let(MyThingInterface.class, () -> new MyThing());

Foo foo = myThing.getMyProperty();

where MyThingInterface is an interface implemented by MyThing. This would probably be even more useful in the junitMixin where you may be likely to be reading properties of properties and the pattern would encourage an interface facade against all the commonly accessed things in the mixin, which can then easily be used.

@greghaskins - what do you think of this? I think it can be done in about 20 lines of neat code and added as an overload to what we have - essentially it's a shim to convert a Supplier<T> to an R where T extends R and the object of R is just a dynamic proxy to the object behind Supplier.get.

[ashleyfrieze]

@greghaskins do you even slightly care about this? I'm not sure I do anymore :)

[greghaskins]

Let's put this idea on the shelf until we get lots of complaints about the syntax. Some boilerplate is pretty much expected in the Java world these days, so I don't see the extra .get() and .set() as too painful. If people want really slick syntax, they would probably already be using Groovy/Scala/Kotlin, etc.

[ashleyfrieze]

Interestingly one of the comments from that article I fwded was on the clunkiness of this... might be worth keeping open at low priority.

[ashleyfrieze]

@greghaskins - is this still closed?

[basdijkstra]

Again, since @ashleyfrieze invited me to comment, here's my $0.02:

I'd like to see this implemented anyway. Don't think that 'if people expect clean code they'd move to Groovy/Scala/Kotlin' is a good reason not to strive for clean code in Java :)

Plus, it would make using Spectrum that much easier to explain to people that do not necessarily have a ton of programming experience.

[greghaskins]

Alright, I'm on board. Let's continue the discussion over in PR #122.