Open Manbearpiet opened 4 years ago
Several things bother me about this (nice write up btw!).
One, when did documenting for PSv2 become a priority? This syntax is unnecessary, slow, archaic, and completely obtuse:
$dict = New-Object "System.Collections.Generic.Dictionary``2[System.String,System.String]"
Even if this was necessary (it's not, at all) this is probably the slowest and most arcane way you could think up to write this line of code.
$dict = [System.Collections.Generic.Dictionary[string, string]]::new()
That's perfectly serviceable. Please revise your docs. Even if you must support PS4 or below, there's absolutely no need to include the `2
nonsense, nor to fully qualify System.String
; we have type accelerators for a reason.
That aside, this notion of providing a strongly-typed dictionary is all well and good, but it's not very compatible with PowerShell, which often relies on loose type restrictions for convenience.
Even if you must internally use such a dictionary, requiring one as input from PowerShell is just being needlessly difficult. PowerShell provides ample conversion methods for most types to make this easier. It would make interfacing with the cmdlet significantly easier to just do conversions as needed, and accept a standard hashtable as input like the rest of PowerShell does.
[Parameter]
public Hashtable InputParam = null;
// ...
Dictionary<string, string> convertedDict = new Dictionary<string, string>(inputParam.Count);
foreach (var key in InputParam.Keys)
{
convertedDict.Add(
LanguagePrimitives.ConvertTo<string>(key),
LanguagePrimitives.ConvertTo<string>(value));
}
Please design PowerShell interfaces to be compatible with the PowerShell ecosystem. 💖
Yes, we don't explicitly have this in our design guidelines, but it should be there - we have been requiring new cmdlets to follow this pattern for some time, and the cmdlet generator explicitly follows this pattern (Hashtables instead of Dictionary types).
In this case, we would have to worry about breaking changes if we changed the type, but short of that, if we added a type converter so that you could provide inline hashtables, would that resolve the problem?
we have been requiring new cmdlets to follow this pattern for some time, and the cmdlet generator explicitly follows this pattern (Hashtables instead of Dictionary types).
Glad to hear it! 💖
A type converter is one option. Another might be a transformation attribute which handles it just for the parameter.
Unless I'm mistaken, type converters typically affect the whole process/session, right? That might lead to unintended consequences down the road with completely unrelated things.
A PS-centric example/explanation of argument transformation attributes is in this blog post of mine, but it maps pretty 1:1 with C# design (apart from the specifics of the internal logic) for the same functionality. You can reuse the attribute for any other cmdlets which have this older pattern in their parameters as well, without affecting anything else in the user's PS session.
If you'd prefer C# examples, I can also point to the attributes used for PSWordCloud's parameter type transformations (they're quite similar though).
Description
I tried creating an actiongroup today, however I found something in the help of this cmdlet which I haven't seen in a while. The cmdlet forces me to create a dictionary which creates multiple lines of code, where I'm used to creating resources from a single line of code with in example a line like this:
However I'm required to create a dictionary, using New-Object. This seems like a robust, but less user-friendly way of receiving an object which contains a string as a name and a string as a value. Is it possible to explore options to support use of for example hashtables? The steps I've supplied are from the help documentation of New-AzActionGroup. My thanks in advance and I wish you all a pleasant day!
Steps to reproduce
Environment data
Module versions
Debug output
Error output