create convenient "entrypoints" for different MBO variants

[jakob-r]

for example call ego(fun, ...) and no more control objects are needed for simple stuff.

[berndbischl]

For every REASONABLE MBO variant we write a an easy to use function. We will have to reuse the control objects a little bit, I guess. The stuff which is set in makeMBOControl I think we still need?

And before we do this, we should carefully write down the API, so we are SURE we really make stuff easier and dont overcomplicate things.

[berndbischl]

Actually, it might be easier to simply have makeEGOControl? And do the dispatch via that? We can then also make use of "@inheritParams" from roxygen?

[jakob-r]

The reason behind a ego function is that we could also define the surrogate learner ourselves and increase simplicity. On the other hand: Why not both?

[berndbischl]

Both is just confusing for the user and too much too maintain. The reason I like the control object approach much better, is because we dont duplicate so much. An we can still define good defaults for the learner. But: Instead of arguing in the blind, lets just write down here, how both options would look like.

[jakobbossek]

Did the same in ecr. I agree, that it is somehow a maintainence overload, but has some benefits as well especially in hiding the creation of the control object and offering a more "R-like" interface.

[berndbischl]

The thing is: We DEFINITELY want to do this. We are not discussing if we do this, but what API is the nicest approach.

[jakobbossek]

I should read the entire log here and not just the last few postings I guess :smile:

[jakob-r]

I created a branch: You can compare here. I suggest leaving the discussion here and just open the PR when it's really done.

[jakob-r]

See PR #234