Open JustinGrote opened 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...
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:
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)?
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" :)