Not a fan of Classes in Powershell

on Monday, January 21, 2019

Powershell’s most powerful ability is it’s completely dynamic runtime. The Powershell & ISE designers did an amazing job making the entire runtime able to create new functions, new variables, new modules and update them without needing to reload the runtime environment. It’s just always always modifiable all the time. Does that function not work correctly? That’s fine, just update the definition and the runtime will now use the new one. Don’t worry about all the variables and state information you have in the runtime, it’s still there. You don’t need to reload anything else, just update the one thing you want to change and start using it.

So, to go backwards a step … in PowerShell 5.0, classes were introduced. And, I understand why they were introduced. It’s not to make the scripting language more like a typed language, it’s so that the scripting language can do things that were previously only possible in typed languages. Like DI/IoC … more on that in another post.

However, classes in Powershell can only be loaded once. When they are loaded, they are compiled into dynamic libraries and loaded into the .NET CLR runtime that is hosting the Powershell runtime. And because it’s loaded into the CLR runtime, it cannot be removed/updated/altered. With enough work in Rosyln and/or MEF you can probably make the definition slightly dynamic with different versions of multiple dynamic library definitions; but that’s not the way Powershell classes work. They are only loaded into memory once and you are stuck with it until you create a new Powershell runtime. And creating a new Powershell runtime means losing all of your variable and state information. It’s a real drag.

Of course, there are some really difficult ways to alleviate these problems; but those solutions would take much greater minds than mine to implement. Two ways that I think might be possible are:

  • The .NET CLR team would need to implement an ability to Unload an assembly. I’ve read enough forum posts to understand just how insanely difficult that is to do, and that’s why I don’t have any criticism for it not being implemented. It was a design choice and it’s really really hard to actually implement.
  • The Powershell Runtime team could implement classes differently where they wouldn’t be turned into .NET assemblies. Instead they would be something natively within the Powershell runtime. Where the type system that Powershell supports would treat them just like .NET types, but they would actually be in the Powershell runtime and be completely dynamic.

Anyways, because Powershell classes don’t follow the structure that everything in Powershell should be dynamic and always modifiable within the runtime, I just can’t be a fan of using them.

0 comments:

Post a Comment


Creative Commons License
This site uses Alex Gorbatchev's SyntaxHighlighter, and hosted by herdingcode.com's Jon Galloway.