Re: Make GET_LISTENER take a pointer arg and deduce its type (issue 549890043 by address@hidden)

[dak]

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/