Simplify use of arbitrary custom transforms in the `Adapter`

[vpratz]

The removal of the LambdaTransform leaves a hole that needs to be filled, as arbitrary custom transforms are something that we require in our projects. Implementing custom transforms via subclassing is possible, but requires a lot more boilerplate, and is harder to get right. If one wants to combine it with the FilterTransform as was possible with .apply, the complexity increases even more.

I personally think what LambdaTransform and .apply offered was a very convenient wrapper, that let's users focus on the main part: Writing the forward and inverse transform. in the constructor of LambdaTransform, we could check if the provided functions are already registered and therefore serializable. If they are not, we can warn/error with instructions of how to achieve that (which is: put a decorator before the function). This could be accompanied by a more detailed tutorial-style notebook, that can also be linked in the warning. In my opinion, this should be sufficient to get the power users that want to use such transforms on the right track, and be able to alleviate the concerns regarding serialization.

Please let me know what you think.
@LarsKue @stefanradev93 @paul-buerkner @elseml

[paul-buerkner]

I agree. Could you prepare a PR for this?

[vpratz]

Yes, I can do it, but it might take some time until I get to it.

[LarsKue]

I'm all for the idea of having this transform, which is why I (haphazardly) implemented it in the first place. Unfortunately, beginner users often fall into the serialization trap, but I like your suggestions. Still, I think it should not be as easily exposed on the adapter, unless the warning is very explicit on what to do (i.e., should provide an immediate code fix that users of any skill level can just copy and paste).

[vpratz]

Great. My idea would be that in addition to possible checks, we can use inspect.getsourceto provide an example of how to decorate the function the user provided (this should be copy/pastable). We could also think about storing this string during serialization, in case the function is not registered when deserializing. We could then tell the user how the function they provided had looked like, and that they have to register it again before deserializing.

[LarsKue]

@vpratz yes, that sounds great.

[LarsKue]

@vpratz any updates?

[vpratz]

Not yet, I'll try to implement it sometime this week.

[vpratz]

Closed by #399.