I am still missing a use case that validates such changes... adaptTo is already a slightly hacky/magic approach, we should not introduce more magic :)
Cheers, Alex On 28.07.2014, at 21:49, Marius Petria <mpet...@adobe.com> wrote: > > Hi, > > I just read this thread and it might be that I do not understand all the > reasons behind surfacing exceptions through adaptTo. However, I wanted to > share with you a variation of Bertrand¹s initial proposal which allows the > consumer of the API to explicitly require an adaptation that throws > exceptions. > > Instead of > > * Foo f = someObject.adaptTo(RequireAdapter<Foo>.class)); > > One can use a double adaption > > * StrictAdaptable strictAdaptable = > someObject.adaptTo(StrictAdaptable.class)); > * Foo f = strictAdaptable.adaptTo(Foo.class)); > > where StrictAdaptable is just like Adaptable but in addition it specifies > that adaptTo never returns null and can throw RuntimeExceptions. > > The boiler plate of ³double adaption² can be extracted in an adaptOrThrow > util. > In case of validation a more specific interface (ValidationAdaptable) can > be used, for which the contract of adaptTo specifies that it throws > ValidationException. > > WDYT? > > Marius > > > > > > > > > > > > On 7/3/14, 12:06 PM, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote: > >> Hi, >> >> On Tue, Jul 1, 2014 at 5:16 PM, Felix Meschberger <fmesc...@adobe.com> >> wrote: >>> Am 01.07.2014 um 09:44 schrieb Bertrand Delacretaz >>> <bdelacre...@apache.org>: >>> ...Unfortunately, I don't think this works, because the adaptTo >>> signature is: >>> >>> public <AdapterType> AdapterType adaptTo(Class<AdapterType> type); >>> >>> Hence the return type is the same as provided as the argument, that is >>> if you pass >>> RequireAdapter<Foo>, you get a RequireAdapter<Foo> object and not a Foo >>> object... >> >> You're right, I overlooked that. >> >> The someObject.adaptTo(RequireAdapter.for(Foo.class)) variant should >> work if for(...) returns Foo.class but uses a ThreadLocal to tell the >> AdapterManagerImpl about the options. Not sure if it's worth the >> effort or if a new API is better, we could implement a bridge between >> the new and old API to avoid having to change all existing adapters. >> >> I see that the use case is under discussion anyway, so let's see what >> comes out of that... >> >> -Bertrand >
