ParameterSetName - How to handle multiple mutual exclusions

What if I have multiple mutual excluions such as:

Path vs LiteralPath and Time vs FileWithTime where I need either Time or
FileTime to work in conjunction with either Path or LiteralPath. How do you
do that with the ParameterSetNameAttribute?

--
Keith

There's no direct native mechanism for handling complex usages like that.
This was one limitation the developers mentioned in private beta days.
Trying to represent it in Get-Command would get pretty complex as well,
since there are 4 distinct usage statements from that set.

The approach I've used is to refactor parameter sets like this.

Assuming this is your touch cmdlet, here's how I would probably approach it.
I would change this back to a single parameter Time, but make it an object.
If it is a filesystem object or a path to an object, you get the time from
the object's timestamp. If not, it's parsed as a time.

Frankly, I would also like to see them change the string[] LiteralPath to
just Switch Literal to modify the treatment of the Path parameter. That
makes syntax much simpler.

"Keith Hill [MVP]" <r_keith_hill@mailhot.moc.nospam> wrote in message
news:uRjXNiS1GHA.1040@TK2MSFTNGP06.phx.gbl...
> What if I have multiple mutual excluions such as:
>
> Path vs LiteralPath and Time vs FileWithTime where I need either Time or
> FileTime to work in conjunction with either Path or LiteralPath. How do
> you do that with the ParameterSetNameAttribute?
>
> --
> Keith
>

"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:eTJc%23PT1GHA.1288@TK2MSFTNGP03.phx.gbl...
> There's no direct native mechanism for handling complex usages like that.
> This was one limitation the developers mentioned in private beta days.
> Trying to represent it in Get-Command would get pretty complex as well,
> since there are 4 distinct usage statements from that set.
>
> The approach I've used is to refactor parameter sets like this.
>
> Assuming this is your touch cmdlet, here's how I would probably approach
> it. I would change this back to a single parameter Time, but make it an
> object. If it is a filesystem object or a path to an object, you get the
> time from the object's timestamp. If not, it's parsed as a time.

I'll look into what I can do there. Basically I could accept an Object and
then hurl if it is not either a string that is a valid path to a file, a
FileInfo object or a DateTime object.

> Frankly, I would also like to see them change the string[] LiteralPath to
> just Switch Literal to modify the treatment of the Path parameter. That
> makes syntax much simpler.

Yeah since this complicates your parameter sets by adding Path vs
LiteralPath.

--
Keith

LiteralPath actually started out as a SwitchParameter, but that introduces
some much larger issues.

1) Binding from the pipeine (about 80% of the issue.)

Conceptually, Get-Item <filename> | Get-Item should return the same results
as simply Get-Item <filename>

In RC1 builds, the Path property of the incoming object gets bound to the
Path parameter of the cmdlet. Since the Path property of the item can
include wildcard characters, this means that the second Get-Item command
will still do wildcard expansion.

In RC2, the incoming PSPath parameter is instead bound to the LiteralPath
parameter, which does no wildcard expansion.


2) Multiple literal parameters (about 20% of the issue.)

While "Get-ChildItem <Path> -Literal" may make sense, you get into a serious
naming issue if a cmdlet supports mulitple wildcard parameters. For
example:

Select-String -Path <path> -TreatPathAsLiteral -Match
<pattern> -TreatMatchAsLiteral


Granted, the parameter set explosion is something that is uncomfortable
right now, but can be solved in a future release.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Keith Hill [MVP]" <r_keith_hill@mailhot.moc.nospam> wrote in message
news:%23gJg3rT1GHA.3908@TK2MSFTNGP05.phx.gbl...
>
> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
> news:eTJc%23PT1GHA.1288@TK2MSFTNGP03.phx.gbl...
>> There's no direct native mechanism for handling complex usages like that.
>> This was one limitation the developers mentioned in private beta days.
>> Trying to represent it in Get-Command would get pretty complex as well,
>> since there are 4 distinct usage statements from that set.
>>
>> The approach I've used is to refactor parameter sets like this.
>>
>> Assuming this is your touch cmdlet, here's how I would probably approach
>> it. I would change this back to a single parameter Time, but make it an
>> object. If it is a filesystem object or a path to an object, you get the
>> time from the object's timestamp. If not, it's parsed as a time.
>
> I'll look into what I can do there. Basically I could accept an Object
> and then hurl if it is not either a string that is a valid path to a file,
> a FileInfo object or a DateTime object.
>
>> Frankly, I would also like to see them change the string[] LiteralPath to
>> just Switch Literal to modify the treatment of the Path parameter. That
>> makes syntax much simpler.
>
> Yeah since this complicates your parameter sets by adding Path vs
> LiteralPath.
>
> --
> Keith
>