[MonoDevelop] Some changes to ambiences

Mike Krüger mkrueger at novell.com
Sat Nov 29 02:23:48 EST 2008


> The main problem, though, is API usability. Imagine that, as a new
> user of this API, you see the following signature in code completion:
> public string GetString (IDomVisitable domVisitable, object settings)
> You'd have no clear idea what the settings object is meant to be.
> It does not make sense for the public ambience API to reflect the
> limitations of the visitor pattern if we can avoid it.

Ok fixed. We now have: 

public string GetString (IDomVisitable domVisitable,
                         OutputSettings settings)
public string GetString (IDomVisitable domVisitable, 
                         OutputFlags flags)

in the public api and all helper methods became helper properties in the
settings. But the main problem was not the API usability (we've enough
'examples' of using ambiences (monkey see/monkey do learning)) the main
problem was the limitation of the visitor pattern.
The visitor pattern was the bad guy here. Therefore I changed the 

IDomVisitor {
object Visit (Something something, object data);


IDomVisitor<T, S> {
S Visit (Something something, T data);

and the ambiences are using an 'IDomVisitor<OutputSettings, string>'. So
all methods are now looking like:

public string Visit (IProperty property, OutputSettings settings)

I think this'll solve all issues I had with using strong typing and will
also solve some issues with the visitor pattern. No more objects
floating around/no boxing/no ugly upcasts.
Maybe we should introduce typed visitors in nrefactory as well, but
that's a complete different story.


More information about the Monodevelop-list mailing list