December 12, 2016 at 7:43 am #59973
Hi Powershell specialists!
I'm currently updating old modules and try to implement custom classes. I noticed, that I can't use the types while using `Export-ModuleMember *` and `Import-Module Foobar`. So I found the statement / keyword `using module `.
Now everything seems to work until I try to split my code from the module file `.psm1` into seperat files and dotsourcing them.
Let me show you an example:
I hope you can help me with some advice. I really got stuck here^^
December 12, 2016 at 6:49 pm #60007
So... out of curiosity, apart from classes being the new shiny, what're you hoping to achieve by this switch? Bear in mind, too, that classes are still a bit of a work in progress outside of using them to author DSC resources. They don't _quite_ work like a .NET Framework class, for example.
December 13, 2016 at 6:46 am #60087
Well, my goal was to structure the code and simplify the usage of the module for my colleagues. So I started working with PSCustomObjects for function returns an giving them unique typenames. Then I stumbled across this https://youtu.be/bqb5bQgC9qM .
and I thought switching to classes.
But one big downside I noticed was, that I can't use any 'advanced function' techniques from functions for class methods.
December 12, 2016 at 8:14 pm #60046
So yeah... I've been down this road. There have been some great conversations I've seen between Joel Bennet, Jason Shirk (from the PS team), June Blender, and others discussing this, and I don't believe that there have been any changes so far. All of the scenarios described for classes in the v5.0 release notes seem to work just fine if you are only writing scripts, but once you attempt to include them with a module then things go pear-shaped. I struggled with class visibility in modules and ended up just writing some supporting classes in C# instead. I'd still really like this to get figured out and classes to get full support in modules, so I entered this uservoice item:
Please vote it up! I'd really like to see classes get the same type of visibility support that functions and variables get in modules, and the ability to clean them up when we remove modules as well.
As far as use cases go, there are lots of little things that are much improved when you can instantiate custom classes in your functions – better parameter validation, tab-completion/intellisense just to name two. On top of that, it just seems more formal than using customobjects and PSTypename everywhere.
Also, v5.0 isn't really that new and shiny – I think it's been out for over two years now if you count the preview versions, and over a year in production in Windows 10. That should have been plenty of time to iron these problems out. Maybe they just weren't getting much adoption yet and folks are just now taking them out for a spin.
December 13, 2016 at 7:56 am #60088
Just upvoted! Thanks for your detailed explanation. I still try to figure out what's best for me.
Maybe I should still using PSCustomObjects in functions than converting them into class methods with all its disadvantages.
April 6, 2017 at 3:06 pm #67378
Wow, that explains a lot to me.
But it leads to an other problem in my case.
I'm writing mostly module functions where I'm forced to handle a lot of different PSCustomObjects with a unique TypeName.
To simplify the usage for my colleagues, which creates scripts bases on my functions, I'm always hitting the same question:
What's the best solution for this? – Using PSCustomObjects as input and output or would it be easier for my colleagues if i define a proper Class.
But each decision seems to have a downside:
+ defines 100% how the input and output has to be
– Loading the class definitions through a module manifest into parent scopes is a bit tricky.(Past discussion, 2)
– Limits the PS version to >5
PSCustomObject with unique TypeName:
– I think there is no elegant way to validate them when used as input, output
– No simple way to to create an other instance of it.
+ Simple creation and manipulation.
You must be logged in to reply to this topic.