Announcement

Collapse
No announcement yet.

Is IPlugin something that external developers can use?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Is IPlugin something that external developers can use?

    I was wondering about doing something like IL-rewriting / code-injection but with Bridge. For example, if I'm taking my war on nulls seriously and have "if null throw ArgumentNullException" guards for every argument in every method (because I use an "Optional" struct for any argument that may not have a value).. then that's a lot of "if null throw" checks (I use code snippets to make writing the guard clauses painless but it's still a lot of noise in the source code).

    This isn't an original thought on my part, there's a Phil Haacked from 2013 about something similar: Mitigate The Billion Dollar Mistake with Aspects.

    I thought that a Bridge plugin might make this possible. Before I tried going down that route, though, I had a couple of questions - are plugins the sort of things that you expect to be custom and user-distributable? For example, would it be feasible to include a plugin in a NuGet package? Secondly, am I correct in my understanding that plugins are allowed the C# source code to be changed before the translation-to-JS occurs; so I could inject the guard clauses into the tops of methods in the in-memory source code before translation (without having the changes persisted in my actual source code files)? Thirdly, is IPlugin going to change completely when Roslyn is used in favour of NRefactory?

    Thanks in advance for your help!

    #2
    Hi ProductiveRage: I've sent you an email with some info.

    Comment


      #3
      Few words about Bridge plugins system, it is still quite limited (functionality) system which does not provide full set of abilities to modify source code. We need to review functionality of plugin system in future. Plugin system was created basically to implement few Bridge plugins which are not publicaly released yet. We need to change plugin API for using it by developers (for example, add more entry points which allows to involve on each translation step)

      First, plugin system was designed to generate additional javascript code (for example, plugin can override of GetConstructorInjectors of AbstarctPlugin and inject required javascript directly to javascript constructor). Also, you can track some events in plugin (like, Before/After type emit, after output and etc) and perform some actions

      Second, it is not designed to modify C# source code before Bridge compilation. However it is very useful functionality. Bridge uses NRefactory rewriter classes to modify some C# statements before translation and I guess we should add support of custom Roslyn CSharpSyntaxRewriter classes which will be used the same way. It is not difficult but can provide a lot of advatages for developers
      Last edited by geoffrey.mcgill; 2016-08-29 @ 06:49 PM.

      Comment


        #4
        I know that you guys are really busy with the next release so I'm not expecting anything too soon, but I was thinking about this again today and wondered if you had any more idea how IPlugin might work now that Roslyn has replaced NRefactory.

        A generic approach to altering the C# source, using Roslyn so that any experience with Roslyn analysers could be reapplied to Bridge plugins, would be excellent. If it would help to have a more specific idea of what sort of thing I'm talking about, I'll try to describe what I'm currently imagining..

        I'm experimenting with React to see how many elements may be drawn on a page before it starts to feel slow. Each element has a Props reference, which is configuration information for the element (it might be something as simple as a class with a Text property, which is what will be displayed on a label element). React expects props references to be immutable, so I model my props classes using immutable classes in C#.

        However, when drawing 1000s of elements, the overhead of creating each class starts to contribute to the total render time. If I replace the immutable props class with a simple mutable one with [ObjectLiteral], then that time is avoided. However, I've then lost type information (if React considers it an error to try to mutate a props reference then it's really valuable being able to represent that in the C# type system). I'm contemplating some sort of mechanism (presumably a plugin) that could perform some analysis and replace simple props classes like this before translation - that way, the C# type system would see them as immutable but they would be plain object literals in the JavaScript code.

        I realise that, in the example above, I could do this manually by adding the [ObjectLiteral] attributes myself to the props classes but I like the idea of being able to include automatic and transparent performance improvements "behind the scene" with my NuGet packages. It could also mean that newer versions of the library / NuGet package could include new performance improvements that don't require whoever is consuming the library to update any of their code - they would just rebuild their code with the new package and things would magically be faster.
        Last edited by geoffrey.mcgill; 2016-08-27 @ 03:17 PM.

        Comment


          #5
          Thanks for the feedback. We are discussing.

          Comment


            #6
            Did you guys have any more thoughts on this? I was thinking about it again recently and wasn't sure where things were at.

            Comment


              #7
              Hi ProductiveRage,

              We just had a team discussion.

              We plan to expose (to recommend for using) the current Plugin API in next major releases when it gets stable and tested.

              The current API is considered as experimental and will be changing.

              Comment

              Working...
              X