PowerShell is still sometimes called "Monad" or "MSH" in documentation

Created on 29 May 2020  路  5Comments  路  Source: PowerShell/PowerShell

In some places, the PowerShell SDK documentation, and possibly other documentation, though I haven't checked thoroughly, still refers to "Monad" or "MSH," PowerShell's previous names during its original development. This has the potential to confuse programmers who are not aware of PowerShell's history.

As particular examples, this can be seen in Cmdlet's and RuntimeException's SDK documentation, but it also occurs in many other documents.

As a documentation problem, this issue was originally opened as MicrosoftDocs/PowerShell-Docs#6043, but it was closed and reopened here because the documentation in question is generated from /// doc-comments in the PowerShell codebase itself.

Area-Maintainers-Documentation Issue-Question

Most helpful comment

I'd like to see the file that contains PSObject renamed from MshObject.cs because that's super confusing (same with MshCmdlet.cs). I don't really see a reason to change the class name of MshCommandRuntime for instance though. As long as their internal, it's probably not worth renaming any actual classes.

All 5 comments

There are quite a few internal code comments that use the Monad / MSH / Monad Shell moniker as well. Some of the internal class files / classes themselves also bear that name, MshObject is one example.

Probably worth going through and renaming a fair few things to align with the current name sooner or later... there will be a fair bit though, I'd imagine.

@vexx32 Certainly not a high-priority issue, but something to take care of eventually.

Sounds like a good October fest ticket.

Way back in version 1.0, just before releasing, we made a pass through all of the code and docs renaming everything Monad/msh that was public. Clearly we missed a few in the docs that should just be fixed. However all of the internal members were (obviously) not renamed.. We reviewed the code again prior to going open source, and again saw no compelling need to churn the code for trivial reasons. This has been the status quo for over 13 years. What compelling reason is there to change this now?

I'd like to see the file that contains PSObject renamed from MshObject.cs because that's super confusing (same with MshCmdlet.cs). I don't really see a reason to change the class name of MshCommandRuntime for instance though. As long as their internal, it's probably not worth renaming any actual classes.

Was this page helpful?
0 / 5 - 0 ratings