My feedback about SyntaxEditor (and .Net add-on)

Hi Nicolas,

Thanks for the feedback.

1) I don't believe the AmbientAssemblyRepositoryProvider being possibly changed by another extension will cause an issue.  Basically it is designating a caching mechanism.  So if you go an try to add a new reference to another .dll, it would just use the other extension's designated cache location instead but everything should continue to work ok for you.

Changing the AmbientParseRequestDispatcherProvider shouldn't cause issues either since from that point on, the new parse request dispatcher would simply be used instead to call your parsers.

2) We have that on the TODO list, to consider using Cecil as an alternative way of loading code.  However since it's open source, it would have to be in a separate .dll from the rest of the .NET Languages Add-on assemblies.

3) As mentioned in the other thread, if it can't determine that an overload exactly matches, it has to fall back to something.  It will do its best to find the closest match.  In the case you said, it found an overload of Sum that had the same parameter count.  I checked in VS and it does the same thing.  The difference in VS is that you also get compiler error squiggle lines, but we can't do that since we don't have a compiler wired up, only a syntax checker (and the syntax is techincally correct).

Hi,

Thanks for this reply. I look forward to the integration of Cecil !

Concerning the determination of the method overload, I understand that parsing is not enough. But precisely, .Net add-on is more, as it implement a resolver. I read the article http://www.actiprosoftware.com/community/thread/21463/no-error-if-method-parameters-are-wrong of Christel and I can actually add a treatment after the parsing stage but in my opinion I do not need more information than that provided by the resolver. So, I wonder why this is not integrated into the standard operation of the product.

Regards,

Nicolas

Hi Nicolas,

We will write down the suggestion, but note that the resolution of every identifier in a document would slow down the parsing phase in large documents, meaning outlining, and other syntax errors would take longer to show up.  A larger problem is that the reflection data for the document being parsed doesn't get updated until after the parsing completes and ICodeDocument.ParseData is changed.  Running the resolver prior to that (as a piggyback on the parsing phase) then wouldn't have the current reflection data, which would lead to false resolver errors.