Naming Roslyn concepts


We have a rather central component in Roslyn and we’re looking how to name it best. I’d like to gather some advice and opinions that could potentially help us find a good name.

I am intentionally not mentioning what is it called right now. Instead, I’m going to describe it. If you recognize this component from the Roslyn CTPs, please don’t name it in the comments so as not to accidentally drive others towards its current name, which we believe is overused in our domain already.

Roslyn analyzes code. Code is most often organized into solutions, projects and documents. Primarily we use three types to model source code: Solution, Project and Document. A Solution has a set of Projects, a Project has a set of Documents. These form an immutable tree that captures a snapshot of a source code tree at a moment in time. This data structure only captures the information interesting to the compiler, it’s not an MSBuild or a project system concept. When the user edits the text of a document in the editor, adds a new project in Visual Studio or otherwise modifies code, a new immutable snapshot of the entire Solution is created. This is implemented using efficient immutable data structures that reuse most of the data between the snapshots. This way if an analysis was in progress while the user changed code, the analysis can continue on it’s own snapshot safely knowing that the snapshot will never change. Also we can utilize multiple cores for fast, safe, lock-free analysis.

Now, the concept we’re looking to name is something that has a CurrentSolution property that points to the latest snapshot of the solution data structure. It can listen to changes in user’s source code, build a new Solution snapshot to reflect those changes, and finally update the CurrentSolution property to point to the latest snapshot. This concept also has an event that our features can listen to to update themselves when the current solution has changed.

An environment that is hosting Roslyn (say the Visual Studio project system) is responsible for forwarding changes into this component such that it can recalculate the most up-to-date Solution and notify all observers.

If a Roslyn feature, such as a refactoring, wants to modify the users code (e.g. generate a method), it doesn’t talk directly to the environment. Instead, it describes the changes it wants to apply to the current solution and forms a new, delta (diff) Solution, and hands it off to our component. Our component then takes this delta (changes) and sends it back to the host, asking the host to do whatever is necessary to actually apply these changes (edit a file, checkout a file from TFS, add a reference, etc.) The host then, after applying these changes will pipe the notifications back into our component to complete the circle.

How do we name this component that is responsible for keeping the CurrentSolution up-to-date and ensures bidirectional communication of changes with the host environment?

Thanks!


Comments (28)

  1. Thomas Levesque says:

    How about SolutionContext ?

  2. Jesse Houwing says:

    SourceService? (or something mythical such as Druid or Ent, you're explaining something that can communicate with trees here ;)).

  3. Mike Strobel says:

    +1 for SolutionContext, or perhaps SolutionTracker.

  4. Jack says:

    SolutionProxy? SourceSnapshotService? SourceSnapshot? SolutionSnapshot? SolutionModel? SolutionSourceModel?

  5. Andrey Shchekin says:

    1. SolutionHost

    2. SolutionHostMediator

    3. SolutionHostContext

    4. SolutionManager

    5. SolutionContextService

  6. Stephan says:

    Sounds a bit like the FileSystemWatcher to me, so SolutionWatcher maybe, although I also like the SolutionTracker.

  7. Sinix says:

    What about the use-case code samples? It's hard to guess the proper variant without them.

    If you're searching for common-use api name, I'd prefer to use most obvious one, e.g. SolutionState.Current (or, if you wish to name the thing as controller, not as a state object, SolutionCoordinator).

    As alternative (if the name is just for internal use), SolutionBackstage / SolutionBaker will suit well.

  8. Martin Stickley says:

    SSS

    SolutionSnapshotSynchronizer

  9. Sumit says:

    How about CompilR in line with SignalR :-).

  10. Vadim Kantorov says:

    SolutionController

  11. Harry says:

    I think it would be beneficial if you defined/listed the "interface" members of this class e.g.

    class [NEWNAME]

    {

      public Solution CurrentSolution { get; }

      // Etc.

    }

  12. Harry says:

    Given that this class will be a eventual consistency (i.e. it will lag behind the current actual state of the solution) snapshot of the solution, "tracker" makes a lot of sense. It is basically tracking or logging code change events to give a snapshot of the current state. In CQRS this could also be called an event projector to make a read model (solution snapshot).

  13. Ryan Clarke says:

    SolutionSecretary

  14. Mihailik says:

    SolutionChangeTracker

    Although if you're scrambling for the right word, it might be a sign that this thing has too many responsibilities.

  15. David Hanson says:

    SolutionSnapshotObserver

  16. Damian says:

    +1 for SolutionTracker/SolutionChangeTracker

  17. Chris Marisic says:

    SolutionState

    Then rename the property to be

    SolutionState.Current or SolutionState.CurrentSnapshot

  18. Jason says:

    My first thought was SolutionManager, although I like SolutionTracker and SolutionState as well.  

  19. Oleg Sych says:

    I think terms Host and Environment match the abstraction you described.

  20. Earlz says:

    What about SolutionBroker? Definition of broker(noun): A person who buys or sells good or assets for others. Simplified definition of your target name: A component which edits the solution on behalf of another component

  21. Rafael says:

    Why not Zoidberg?

  22. SolutionHostAdapter

    SolutionHostBroker

    SolutionHostBridge

    The name must contain both "Solution" and "Host" to be complete.

    If the component is able to work without a "Host" (or does not know what a host is) the "Host" part can be dropped from the name.

  23. DF says:

    SolutionHub

    SolutionInstance

    SolutionDealer

  24. CS says:

    SolutionSnapshotEditor or SolutionSnapshotUpdater…. the "thing" tasked with keeping the "magazine"(a snapshot of content) up to date.

  25. asdf says:

    Workspace 😉

  26. Kirill Osenkov says:

    Yes, we decided not to change it… Workspace it is.