Topics: Developer Forum
Dec 24, 2006 at 8:46 PM
I'm trying to use this but I'm not seeing much value in it. In fact I use Path, LiteralPath and InputObject together far more. I going to try to add a PscxPathPSObjCommandBase class and see if I get anywhere with that.
Dec 24, 2006 at 8:54 PM
too bad c# does not support c++ templates or some kind of static multiple inheritance. it is starting to look a bit messy :(
Dec 25, 2006 at 12:29 AM
okay, that wasnt such a good idea. i guess LiteralPathPathInputObject makes much more sense. and it seems to me it is less likely to cause an inheritance hell, since it does not impose any requirements on the implementing class.

the good news is, i think found a way how to encapsulate the encoding parameter in a composable way. it is not so simple on the implementation side as the inheritance, but it is also not so dangerous.

i implement a structure EncodingParameter, similar to the SwitchParameter, which will convert from/to string, and will contain the selection logic. only thing you need to do, is to add the parameter property. hmm???

BTW, we shouldnt use the ValidateSet attribute on this parameter. It accepts all encoding names known to .net, not only these enumerated unicode encodings.
Dec 25, 2006 at 2:57 AM
Re ValidateSet, I'm just following the PowerShell way on this one. Take a look at Out-File in Reflector and you'll see:

ValidateNotNullOrEmpty, ValidateSet(new string[] { "unicode", "utf7", "utf8", "utf32", "ascii", "bigendianunicode", "default", "oem" }), Parameter(Position=1)
public string Encoding { get; set; }
Dec 25, 2006 at 4:10 AM
but we support all .net encodings (by the Encoding.GetEncoding(..) fallback). i dont know the reason why powershell commands support only the hardcoded eight, but i guess it wont hurt anybody if we support more
Dec 25, 2006 at 7:03 AM
The reason is because this parameter supports binding via ValueFromPipelineProperty. Take a look at the static members of the "Encoding" class:

text.encoding | gm -static

ASCII Property
BigEndianUnicode Property
Default Property
Unicode Property
UTF32 Property
UTF7 Property
UTF8 Property

Look familiar? That's all the encodings supported on the Encoding class and apparently some objects have an encoding property that reflects this. BTW if you try to pass in UTF8 to System.Text.Encoding.GetEncoding and it will fail. All the UTF* names need to be UTF-*. So for now, I'm going to stick with the way the PowerShell team does this for the rest of PowerShell for the sake of consistency.
Dec 25, 2006 at 7:04 AM
Which is why we have the big switch statement instead of using Encoding.GetEncoding().
Dec 25, 2006 at 11:50 AM
and what if somebody wants to use different encoding? say, iso-8859-2, that is used a lot here in central europe, especially on unices, so you are likely to encounter it. and im sure there are more legacy encodings like this one. maybe we should provide Get-Encoding and Convert-Encoding commands?
Dec 25, 2006 at 12:13 PM
BTW the encoding parameter from the FileSystem provider is of type Microsoft.PowerShell.Commands.FileSystemCmdletProviderEncoding. why dont we use this enum then?
Dec 26, 2006 at 12:25 AM
Weird. I guess they were really wanting to extract the Encoding by property name and the type of that property (.Encoding) isn't an enum???
Dec 26, 2006 at 1:15 AM
I think it has nothing to do with the static properties of Encoding class. They are using a switch, just like us.

But the main question is: do we want to support more encodings? I'd deviate in this from the powershell standard, as I see no benefit for the user other than the slight inconsistency itself. I guess nobody will notice when we support the constants from the FS provider enum.