-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Various PowerShell Class Issues #6652
Comments
Have For example I have had to implement GUIs while overriding the WndProc method before. So a way to override methods would be a great addition to Powershell classes. Edit:I noticed #6418 suggested overriding property setters and getters. I suppose that is similar to this. |
Is there any community projects that work around these issues for example? I cannot for the life of me get a decent project implemented in PS w/ classes broken out into a sensible manner without running into one of the above issues.. |
@christru You can take a look at my PoshBot module here: https://github.com/poshbotio/PoshBot That module is almost entirely PowerShell class based. |
@devblackops as I’m litterally watching your YouTube video talk on classes. Thanks buddy! |
@christru Cool. I did the same talk at the PowerShell Summit. It is a more polished version. https://www.youtube.com/watch?v=i1DpPU_xxBc&list=PLfeA8kIs7CocGXuezOoYtLRdnK9S_Mq3e |
@IISResetMe currently classes don't allow overrides. Wouldn't the |
@rjmholt well, we already mark all generated methods class PleaseDisposeOfMe : IDisposable
{
[void]Dispose(){ <# free unmanaged resources #> }
} but since we never mark the underlying get/set methods of properties virtual (looks like an oversight), you can't actually implement an interface with a property: class MyPrincipal : System.Security.Principal.IPrincipal
{
[System.Security.Principal.IPrincipal]$Identity
[bool]IsInRole()
}
At line:2 char:1
+ class MyPrincipal : System.Security.Principal.IPrincipal
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Error during creation of type "MyPrincipal". Error message:
Method 'get_Identity' in type '<404e3736>.MyPrincipal' from assembly '⧹powershell, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : TypeCreationError |
Forgive some ignorance on my part, but looking at the number of issues and the complications that exist in classes in PowerShell today, I can't help but feel this is a design problem rather than a collection of issues/bugs to be addressed. Wouldn't it make more sense and be much easier if:
One of the drivers behind this approach is that it would do away with the need for There are more thoughts behind this, but I've shared enough to see what others think for now. |
On second thought, I'd prefer not having to deal with |
My random thoughts:
|
Yeah, clearly it would be a great thing if Importing a module automatically included Cmdlet-derived classes as commands. But that circles around to @lzybkr I don't quite understand why you think leaving off the Of course, I also think we should actually namespace the classes by module (i.e. |
Uh, I wasn't suggesting "outputting them" either - you define a class in a psm1, it's exported. All classes are exported, simple as that. I was never a fan of the And classes are modeled more like an assembly - public types don't require any entries in the module manifest. The need for |
Any chances we could get constructor chaining on the radar at some point, too? 😄 |
@rjmholt rjmholt One of my old issues about classes (from MS Connect) was not on your, so I search all issues open (missed + new) and compare with your list : #1760 Inheritance from class with abstract property is inconsistent |
I began to report classes issues with PS 5.0 Preview April and nothing has changed in 4 years. (no interface, forbidden methods names not consistant, override isn't implemented , bugged using...) From my point of view, there is only one solution to solve this big issue :
This SuperClass need a very big improvement in the parser because we don't want another limited classes. To be clear, I want a class parser like PSLambda for Roslyn. I don't know if, writing a new extended parser and asking Roslyn to do the job, is more difficult than resolved all these issues. But we are all waiting for a real statement from PowerShell comitee around classes. @SteveL-MSFT To be honested, the aim behind classes are not to write 2 or 3 + 10 methods ... functions already do that ! Can we take a full scenario to determine priority ? I've got one if you want : AspNet Core on PowerShell. (even IronPython had this scenario in net4) I want to resolve this issue in priority because it's very very dangerous : #5332 |
For reference #9382. Maybe we could make friends with these areas. |
Hi. Can you please add Named and Optional Arguments (C# Programming Guide) to the list? |
Didn't see this in the issue list, I can create a separate issue: The array representation of a class (e.g. #Class.ps1
class Test {[String]$Name}
Will error with EDIT: This was actually more of a Pester thing, -BeOfType doesn't work with Powershell Classes. Workaround: Use |
@JustinGrote Please open new issue to discuss your scenario. Then I could add the issue to the tracking list. |
But this is a meta issue. What activity is expected? |
@ForNeVeR @SteveL-MSFT |
To add to the list in the initial post: |
@StevenBucher98 A lot of the issues on this rollup are now marked as closed. Another casualty of this "close everything" policy. At the very least, could the close bot close them as "not planned" rather than "completed?" |
Another one to add to the list (a |
A note to this megathread that most of these issues are not actually fixed, they were just closed by the autobot. |
Meta-issue to track work on improving the experience of PowerShell class usage as much as possible.
Note on By-Design Behaviours
PowerShell classes currently are a bit finnicky. Some of this is a necessary pain because of the design constraints behind classes.
Classes are currently implemented as compiling to .NET IL so that we can take advantage of the .NET object model. Not doing this would mean us reinventing (and having to maintain) the wheel on essentially all object-oriented features available in .NET (or anywhere else) and paying a high runtime overhead on shimming compatibility with the .NET object model (e.g. faking inheritance from .NET classes).
Instead, we compile PowerShell classes to dynamic assemblies and bake in calls to PowerShell in the generated IL. To do this at runtime would mean either breaking dynamic- and module-scoped behaviours in classes, or emitting a new dynamic assembly every time we hit a class definition (and since PowerShell's highest compilation unit is the scriptblock, and scriptblocks are permitted in for-loops, the performance penalty here could be extreme). (I'm still a bit hazy on the details about the mechanisms here, especially in terms of why caching is made impossible by module scope or in comparison to
Add-Type
, but @daxian-dbw or @lzybkr will be able to add to/correct me).The need to compile classes at parse-time means the types required to define a class (in IL) must also be known at parse-time. The module-scoping issue means that a
using module
statement is required to import classes from modules (@daxian-dbw might like to add information here about the specifics governing this need), or by exporting class usage in PowerShell functions (classes having a sort of module-private behaviour).Issues to Improve
There are, however, a few improvements possible to PowerShell classes that might not run up against the design constraints given above. Below is a list of open issues for classes in PowerShell.
Classes in modules
Import-Module -Force
.ScriptsToProcess
withusing module
stops classes from being importedusing module
imports nested module classes in a script but not interactively.using module test
doesn't load the powershell class defined in 'test' if 'test.psd1' has 'FunctionToExport' or 'CmdletToExport' specified #4112using module
doesn't load classes whenFunctionToExport
orCmdletToExport
are specified in the.psd1
using module test
can only load the classes defined intest.psm1
but not other .psm1 files #4114using module
does not find classes in nested modules.New-Module
problem).Type errors
Using external types / classes in Custom PowerShell Classes (v5) results in Parsing Error #2074 Types not available at parse-time used in PS class bodies cause parse errors. @daxian-dbw noted that we need some types at parse-time (such as method return type) to generate the IL, but type resolution inside method/constructor scriptblocks may not be needed and be more appropriate at runtime.Noted as by design.Other bugs
New-Object
does not work for PS classes as it does for .NET classes.protected internal
method of base class. #7622protected internal
override doesn't work (program diverges on method call).New feature requests
static extern
methods and struct definition in PowerShelluse static <class>
usage to allow static member access in PowerShell #5099 Static class member importsenum
types other thanInt32
A couple of other resources on these issues:
using
statement: here.The text was updated successfully, but these errors were encountered: