Re: [FR-devel] Re: Debugger

[Laurent Julliard]

Rich Kilmer wrote:
> comments below

> > Another comment on the use of commands in the EditPane plugin. Beside 
> > the discussion about where/when command should be declared (see 
> > previous message) there is another point that I'd like to discuss:
> >
> > All Edit Panes commands are declared in one single attach_commands 
> > method. After thinking about it I think we should not do that 
> > but keep 
> > each method separate and then call the method from the command proc. 
> > It add an extra methiod call but it has several advantages:
>
>
> Actually, the edit pane itself (in GuiCore) does not do this.  The
> EditPaneRenderFox does.  The EditPane is the API...the slots are
> documented there.  The way in which a renderer fulfills them is up to
> the renderer.  I don't think we need to break them out into separate
> methods since all they are doing is mounting a proc (one to fulfill is
> EditPane command).
>
>
> > a) the code is much more readable with separate methods
>
>
> I don't think that adding all those methods would necessarily make the
> code more readable, but that's in the eye of the coder ;-)
>
>
> > b) with separate methods you can use rdoc and generate good looking 
> > developer documentation
>
>
> The developer documentation should be against the abstraction (EditPane)
> not the renderer.
>
>
> > c) it gives an additional flexibility in the sense that from inside 
> > the plugin you can directly call the methods without the overhead of 
> > the command mechanism.
> >
> > Do you agree with this?
> >
> > If so then I think I can rework the EditPane files a bit to make this 
> > happen. Plus I think it gives an intuitive guideline wrt to when a 
> > command must be created: use a command declaration whenever you want 
> > to publish a command to the outside world for use by other plugins. 
> > Does this sound ok?
> >
> > Laurent
>
>
> I don't think I am following you on this. The EditPane API is that
> presented by the abstract component (in GuiCore).  The "commands" it
> uses are fulfilled by something (actually right now most of the
> "commands" are fulfilled by EditPaneRenderFox with the exception of
> parse_code which is fulfilled by the SoureParser plugin).  The
> "commands" you publish to the outside world are in the databus.  These
> are not the same as the Commands that are bound to Keys, etc.  Maybe its
> not a good idea to overload the command term.   Perhaps it should be
> "behavior" or something.
>
> Does this make sense?
>
> -Rich

I'm still not convinced that having a big blob of flat code in 
attach_commands is the right approach for defining commands.  From a 
developer standpoint I think code readability suffers a lot. I think 
it would be better to have individual *private* methods and then build 
the commands from those methods. I know that we don't want people to 
use these methods (hence the private methods) but developers still 
need to read the code and maintain it. Plus it doesn't break the 
current architecture at all.

I agree with you that we should call 'commands' something different 
(may be 'services' or 'interfaces') because commands is already used 
for menu commands which is sort of misleading

Another side remark: in the course of adapting the Debugger code 
(which you are going to do now) I found it difficult to listen to 
newly created EditPAne slots and only to those ones. In the former 
architecture all EditPanes slots were under a "pool' slot. With the 
current architecture if you create other slots under EditPane other 
than the EditPane instances (1,2,3....) it can be tricky to make the 
distinction when you receive a 'slot_add:' event. May be we should 
consider introducing a 'pool' level again in the ComponentManager so 
if other plugins wants to listen to newly created instances they just 
need to subscribe to the pool slot and be sure that the slot_add 
events they receive are EditPAne instances and not something else.

Laurent