Use conditional on exposing API rather than comments

@zj Mentioned that we could do this at https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1942#note_30151727

expose :prop, using: Entity if Gitlab.ee?

instead of having:

# EE-only
expose :prop, using: Entity

and I think that's a great idea, as this should be loaded at load time, rather than runtime, it shouldn't hurt the performance.

And of course the best thing is that it is not going to cause conflicts as we might have now. The downside might be that then people need to put this on CE, while making the other features and related code on EE, making development much harder and tedious. However this also has some advantages that people would now be very aware that things could be conflicting like crazy if we're not careful enough.

@rymai @rspeicher @vsizov What do you think?

mentioned in merge request !1942 (merged)

@godfat So you basically propose to have a common code for both versions?

@vsizov Yes, and we see EE codes in CE. I am not sure where would the line be, but this should certainly reduce a lot of empty conflicts, which are really annoying.

I think it's ok in principle, but it quickly becomes more complicated if the Entity class is also EE-only. Then we either have to have an empty stub for it in CE, or backport the entire class only to not have it actually do anything, or add more conditionals around defined?(SomeEEClass), for example.

@rspeicher No, we don't have to. Ruby does resolve the constant on runtime (though lexically), if we're sure Gitlab.ee? would be false, the constant could be missing which is completely fine. We cannot test if we don't have a typo there though, of course.

ruby -e 'p Foo if false'

Don't give any error.

Good idea!

mentioned in merge request !2020 (merged)