Re: Python API - nested pretty printers MI implications

[Andrew Oakley <andrew at ado dot is-a-geek dot net>]

On Mon, 15 Aug 2011 17:36:30 +0200
Andrà PÃnitz <andre.poenitz@nokia.com> wrote:
> > > If so, isn't this very similar to the "fat script" approach,
> > > where a python command (fed with a list of "names" of the
> > > expanded items) does all the tree walking by itself? That would
> > > put everything into "user space", let the pretty printers output
> > > additional data that's not of "general" (i.e. for all FEs)
> > > interest, and would make implementation of pretty printers with
> > > multiple phony levels straightforward?
> > 
> > Probably.  But doesn't that mean library writters would get to write
> > pretty printers for each FE out there?
> 
> If the library writer wants to "support" every fancy feature of every
> FE, then, perhaps, yes.
> 
> Anyway, in practice I would expect most implementors of "library
> pretty printers" to just provide the "usual" data (i.e. most likely
> what the current varobjs display looks like), and the FE to override
> a handful of them with an FE-specific "enriched" version - if at all.
> A schism on an individual pretty printer level is certainly much
> easier to handle (especially if the maintainance burden for "fancy
> stuff" is solely on the individual FE side) than a schism on the
> fundamental "varobj vs fat script" level.

OK, so I guess the consensus here is that we should expose the tree
produced by python scripts to MI, including any phony children.  

On Sun, 14 Aug 2011 18:18:30 -0400
Daniel Jacobowitz <drow@false.org> wrote:
> It does seem like a reasonable idea, but watch out for
> CPLUS_FAKE_CHILD; it may not be a good model.  It's used right now for
> public/protected/private groups, and no one seems to want it there -
> it might go away at some point.

I still don't have a better idea for this, so it is probably what I'll
have to go with.  I'll rename it as it won't just be a C++ thing any
more.

If anybody has a way to avoid this then I'm like to hear about it, but I
certainly think the varobj code needs some way to deal with fake
objects that are untyped and have no underlying value.  

On Sun, 14 Aug 2011 18:18:30 -0400
Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Aug 14, 2011 at 12:10 PM, Andrew Oakley
> <andrew@ado.is-a-geek.net> wrote:
> > My other worry is varobj invalidation and update. ÂAm I correct in
> > thinking that updates can only happen from a "root" varobj? ÂIf so
> > it should be possible to reconstruct the "fake" varobj structures in
> > varobj_update (I don't think it will be straightforward though).
> 
> My memory on this is a bit spotty.  I think it may be possible to
> update non-root varobjs, but it's the common case to update the root.
> That might have been an out-of-tree patch though...

Nobody else seems to indicate that this is possible and I can't find
any way to do it.  I think it's probably safe to assume you can't do
this for now.  If we want to be able to update non-root objects in the
front end will probably have to know that the object is phony and
therefore it can't update it directly (or it could try to update it
and get some kind of error).  


The general impression I have got is that MI is somewhat lacking in
"advanced" features and people have just hacked away to get front ends
to do what they want. On this basis it seems sensible to get this change
in and do my best not to break any existing code.  That way when
somebody does decide to rework some of the MI code they will not
overlook the idea of having phony objects (however they are
implemented).  

Unless anyone has any other suggestions or objections I guess I'll
probably start work on this "soon".

-- 
Andrew Oakley