Re: [patch][python] 5 of 5 - Frame filter documentation changes

[Phil Muldoon <pmuldoon at redhat dot com>]

> FrameDecorator also stores this in an attribute, "base".
> Should that attribute just be declared public?
> And if not, shouldn't it be renamed to start with a "_"?
> 
> Phil> +    def function(self):
> Phil> +        frame = self.inferior_frame()
> Phil> +        name = str(frame.name())
> Phil> +        function = str(frame.function())
> Phil> +
> Phil> +        if frame.type() == gdb.INLINE_FRAME:
> Phil> +            name = name + " [inlined from "+ function +"]"
> 
> This actually violates the FrameDecorator guidelines, since it bypasses
> self.base to get the name from the inferior_frame.
> 
> It seems like it should call self.base.name() instead.
> And, it should have a comment explaining why it needs to use
> inferior_frame to call function.

This frame decorator does not have an inferior_frame API declared, so
in the case of the call to inferior_frame, it calls the super class's
inferior_function API (which in this case, will return self.base).
I'll rename self.base to self._base, in the Frame Decorator.  This
example is just deferring the call to the frame decorator that
actually wraps the gdb.Frame.

> Phil> +        try:
> Phil> +            eliding_frame = next(self.input_iterator)
> Phil> +        except StopIteration:
> Phil> +            return frame
> Phil> +        return ElidingFrameDecorator(eliding_frame, [frame])
> 
> What if there are multiple inline frames in a row?
> Wouldn't you want to elide all of them?
> That will make the example trickier though.

Yeah there are several edge cases I did not cover.  I did write an
explanatory passage before this example noting that it just covers one
view, and, there are many other cases to deal with.  I noted the scope
of a manual example can't encompass these.

Cheers,

Phil