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

SyntaxEditor .NET Languages Add-on for WPF Forum

Posted 6 years ago by Nicolas
Version: 13.2.0591
Avatar

I've just released my first software using ActiPro SyntaxEditor (see : www.adaptivelinq.com)

AdaptiveLINQ is a Visual Studio Extension. SyntaxEditor is used as a C# lambda expression editor.

.Net add-on resolver is used to resolve expression type.

SyntaxEditor is a good product but I found 3 defects:

1. Modularity about AmbientAssemblyRepositoryProvider and AmbientParseRequestDispatcherProvider

What happens if another extension of Visual Studio initializes these two static variables ?

2. Assembly repository limited to current framework version

Like I suggest (http://www.actiprosoftware.com/community/thread/20953/assembly-repository-using-an-il-disassembler), the respository should be able to discover an assembly without reflection

3. Strage design about the invalid method detection

See my post: http://www.actiprosoftware.com/community/thread/21346/resolver-fail-to-detect-invalid-method-call. I don't really understand the design rules that explains this behavior


 

Comments (3)

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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).


Actipro Software Support

Posted 6 years ago by Nicolas
Avatar

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

Posted 6 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

The latest build of this product (v2019.1 build 0683) was released 21 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.