Re: [SrcML] new plugin handling and API structure

[Dennis W. <den...@in...>]

On Thu, 21 Apr 2005 17:43:23 +0200
Frank Raiser <fra...@in...> wrote:

[Plugin structure]
Looks ok to me.

> 
> > I meant especially an API plugin. But while normal plugins will
> > usually have  more dependencies I'm not sure that there will be any
> > topologic reorder at all.
> 
> While it might be true that for API plugins a topological sorting is
> unneccessary I still think they should be treated just like other
> plugins. Doing no topological reordering for API plugins creates a
> special case that developers will have to be aware of again. I'd
> sacrifice this little bit of runtime to sorting the dependency tree
> before I require developers to always remember these plugins will be
> an exception to the rule.
I'm not worrying of runtime speed, I just want to make sure that it will
be clear that the topologic sort will not change order of API plugins.
 
> > Since you save language type within a SrcML file you can load a
> > default match  table given by that name. There is no inconsistency
> > because loading a match table would not change the already loaded
> > tree.
> 
> It's not getting inconsistent at runtime. I think the problem is that
> from my point of view it is preferrable to keep a once loaded tree
> fixed. I believe it will create too much confusion if your program
> decides at some point to simply replace the tree with new nodes which
> essentially means that at this point in the program the underlying API
> will be changed.
Of course it would be confusion to iterate a transformation upon a tree.
My intend was to allow for different APIs to be used for the first
transformation from xml to API. If the API was fixed after loading one
could not write a application which handles different languages - unless
he restarts his own program or uses multiple java instances.
 
> > But I guess there's no need to further discuss this matter as we
> > already did that  personally.
> Just to try summing it up for the other readers on this list it comes
> down to a matter of personal taste. The question right now is which
> way will we go for the actual implementation? I especially would like
> to hear other people's opinion about this too.
That would be interesting.
 
> There's also the option to mix both ideas. Let's say a plugin
> specifies two plugins it depends on. Both plugins provide a similar
> methodology which could cause ambiguity. While we could simply throw
> both of them into the dependency graph and basically ignore this
> ambiguity letting either plugin win we could honor the order these
> dependencies are listed in the plugin.xml by adding additional edges
> to the dependency graph. In this case it would mean adding an edge
> from the first plugin to the second to ensure the provided
> functionality of the second will get overwritten by whatever the first
> plugin provides. Therefore the plugin developer can specify the
> loading order dynamically.
That should do the trick too of course.
 
-
Dennis