search

adamedx / scriptclass

Class definition extensions for PowerShell's object-based type system
Apache License 2.0
7 stars 1 forks source link

Why use this over native PS Classes? #35

Open JustinGrote opened 2 years ago

JustinGrote commented 2 years ago

Just a curiosity I have which I think should be called out in the README, why would I want to use this over PS native classes? The feature sets seem to be roughly the same (except for your very clever new invocation "operators" :)

adamedx commented 2 years ago

Just saw this -- great question :). I try to describe the reasons here: https://github.com/adamedx/scriptclass/blob/main/docs/Overview.md#motivation.

That said, I've used this library extensively for the projects at https://github.com/adamedx/autographps-sdk and https://github.com/adamedx/autographps and while it absolutely provided value (those projects are quite complex and I'm not sure I could have managed them over a long period of time without using something "classy"), I certainly could have used PowerShell classes and traded off some usability improvements for (much) better performance and being aligned to the standard.

I do plan to give this one more makeover and call it a 1.0 with an implementation that actually generates the same result as declaring the type with PowerShell. Most of the benefits I describe are found at type definition time and could simply be provided via code generation as opposed to maintaining a parallel type system. And the fun => trick (glad you like it :)) can be implemented on PowerShell classes as well.

At that point the implementation is much thinner and simply becomes a different syntax and interoperates fully the native implementation. We'll see what happens...

adamedx commented 2 years ago

And here's a more direct and concise answer to the original question that summarizes the most important points from the link I shared above:

  1. Using native PowerShell class means adopting .NET method style invocation with comma-delimited lists and parentheses for code that uses those types. Since almost all reusable PowerShell code is command-based, you'll have a mix of two method invocation styles across code. This style mashup is not present in comparable dynamic languages like Javascript, Python, Ruby etc. Besides being inelegant, a case can be made that it can decrease productivity (how many times have people accidentally supplied command parameters as a comma-delimited list in parens and suffered 30 minutes of debugging and staring at the screen when wild, inexplicable behavior resulted)?
  2. There do seem to be some strange behaviors with the PS native types (e.g. type redefinition seems to be allowed) that could cause unexpected problems if scripts are dot-sourced more than once in a session or a module is re-imported.