Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggested namespace rename #6248

Merged
merged 5 commits into from Feb 20, 2019
Merged

Suggested namespace rename #6248

merged 5 commits into from Feb 20, 2019

Conversation

dsyme
Copy link
Contributor

@dsyme dsyme commented Feb 19, 2019

I suppose this is a form of bike-shedding, but the source in our tree doesn't match our binary names, which irks me every time I come to it. We refer to

  • FSharp.Compiler.Private.dll
  • FSharp.Compiler.Service.dll
  • FSharp.Compiler.Interactive.Settings.dll

and so on but our source is always Microsoft.FSharp.Compiler.

Among other things this means you see a wall of text whenever you look at the open declarations at the head of the file on the F# compiler. Personally I think the compiler code looks simpler and more approachable with the shorter, plainer names - everyone knows Microsoft contribute heavily to F# and package it, we don't need to tell them 1700 times in the compiler code.

So I suggest we rename Microsoft.FSharp.Compiler --> FSharp.Compiler in our source.

  • This only affects the internal compiler code and the API of FSharp.Compiler.Service.dll

  • The one exception is FSharp.Compiler.Interactive.Settings, where open Microsoft.FSharp.Compiler.Interactive.Settings can be opened from existing F# scripts. I've added 10 lines to make sure still works

  • This doesn't affect FSharp.Core, which must remain binary compatible. (As background: Back in F# 3.1 we did a while lot of work to allow "open FSharp.Core" to be used instead of "open Microsoft.FSharp.Core". This is in line with that but we can simply rename the source)

  • This doesn't affect the name of the Microsoft.FSharp.Compiler nuget package which is built as part of Microsoft's the distribution of F# in the .NET SDK.

  • This doesn't affect the Visual F# bits.

  • This also does Microsoft.FSharp.Build --> FSharp.Build - again the DLL name is not changed, and the UsingTasks references don't refer to namespaces

@7sharp9
Copy link
Contributor

7sharp9 commented Feb 19, 2019

Ooooh, this would be a good time to check for internal reflection calls :-)

The namespace discrepancy is quite annoying.

fcs/RELEASE_NOTES.md Outdated Show resolved Hide resolved
@cartermp
Copy link
Contributor

This is a good change to make, assuming there aren't some policy issues that come up.

@dsyme
Copy link
Contributor Author

dsyme commented Feb 19, 2019

@cartermp Same test failing again, will need to look into this:

   at FSharp.Compiler.Service.Tests.PerfTests.Test request for parse and check doesn't check whole project() in D:\a\1\s\tests\service\PerfTests.fs:line 75

@dsyme
Copy link
Contributor Author

dsyme commented Feb 19, 2019

Another failure in Test request for parse and check doesn't check whole project

Will re-run and put in a separate PR to diagnose that test

@dsyme dsyme mentioned this pull request Feb 19, 2019
@dsyme dsyme merged commit a26d32a into dotnet:master Feb 20, 2019
nosami pushed a commit to xamarin/visualfsharp that referenced this pull request Jan 26, 2022
* Microsoft.FSharp.Comiler --> FSharp.Compiler

* Microsoft.FSharp.Build --> FSharp.Build

* fix small mistakes

* fix build

* fix flakey test (?)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants