Closed KirkMunro closed 1 year ago
Hmm. Honestly, I think we should be able to just do this with -is 'Dr.Seuss'
; complicating the parsing by introducing the attribute doesn't feel like something we should need to do?
That would mean Pester may need to adjust how it does -BeOfType
to accommodate it in the same way, but I don't think we should have an overly complex syntax for it either way.
3 years later, status?
String vs attribute? Both? String is cleaner, but no way to identify type name from real class (use cases?)? Also inconsistency with parameter-attribute.
Accepted extension for -is
by WG and/or team and just waiting for PR?
The WG doesn't believe that this has too much value if only applied to the is
and isnot
operators. Also, we would be concerned with actual dotnet namespace collisions which would be breaking. We do see that a more fleshed out enhancement to ETS would be generally useful, but this is too specific.
This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes.
Summary of the new feature/enhancement
As a PowerShell scripter who uses named custom types often I want to be able to use the
-is
and-isnot
operators to determine if something is of a custom type so that I can always check for types the same way in PowerShell.Proposed technical implementation details (optional)
The issue here is simple: if you create a custom, named type, and you want to check if an object is that custom, named type, you need to perform that check differently than how you check for any other type.
For example, consider this:
When you hit enter on the last line, the PowerShell parser will be waiting for more input because it recognizes
[PSTypeName('Dr.Seuss')]
as an attribute, and it's looking for either a string or a type name.I would like to change this so that I can use
-is
(andShould -BeOfType
in Pester, which uses-is
internally) to check if an object is a custom object with a specific type name.The workaround is to check the object's
PSTypeNames
property to see if it contains the type name, but since we can identify types on property input in cmdlets using the PSTypeName attribute, it would be more consistent if we could do the same with the-is
and-isnot
operators.