On 2020/04/18 10:26:01, dak wrote: > On 2020/04/18 05:40:53, lemzwerg wrote: > > > What about using two macros instead of one? The first would take a context as a > > first argument (as it does now), the second one uses 'this' in the macro body, > > omitting that as a macro argument. The former seems to be a rarer case than the > > latter. > > Well, the problem is that having GET_LISTENER (... and GET_LISTENER (this, ... > does not really take significantly more space than GET_LISTENER (... and > GET_SELF_LISTENER (... while being less clear about what is happening. > > Similarly for, say, GET_OUTSIDE_LISTENER vs GET_LISTENER (if you try to give the > explicit listener the longer name). > > I agree with the sentiment, but I fail to come up with a naming choice that does > not make the cure worse than the problem.
By the way, the last code iteration has removed specific listener support from the Smob data type. That means that no part of the implementation actually is inherently tied to Listener-specific member functions any more. With regard to your suggestion, that is probably not much more than a philosophical consideration. However, I find the idea of a macro that silently analyses "this" in order to implicitly create a type in case GET_LISTENER is called from a member function actually worse than having it given explicitly. It's like writing something like decltype(this) p; // No guarantee this works instead of Grob *p; in a member function of Grob. https://codereview.appspot.com/549890043/
