How have I gone wrong with a function's parameters list?

function MyFunc ([string]$text)
{
write-host $text
}

function MyFunc1 ([bool]$flag)
{
write-host $flag
}

function MyFunc2 ([string]$text,[bool]$flag)
{
write-host $text
write-host $flag
}

MyFunc("hello")
MyFunc1($true)
MyFunc2("hello",$true)


# The call to MyFunc2 generates error: Cannot convert value "" to type
"System.Boolean". What am I doing wrong?

MyFunc2 "hello" $true

works fine.

your syntax would be right when calling a dotnet method, but for a
powershell function what you are doing is with

> MyFunc2("hello",$true)

is passing an object[] array with two items in it as the input.

> your syntax would be right when calling a dotnet method, but for a
> powershell function what you are doing is with
>
> > MyFunc2("hello",$true)
>
> is passing an object[] array with two items in it as the input.

Thank you. That's the information I've been looking for all afternoon!

After some testing:-

# this works
MyFunc2 "hello" $true

# these don't work
#MyFunc2 ("hello" $true)
#MyFunc2 ("hello", $true)
#MyFunc2 "hello", $true

I think that what is confusing is that in some ways PowerShell is "very .NET
like" and in other ways it isn't. I've been converting some boilerplate C#
and VB.NET into PowerShell script, and for the most part it goes smoothly...
but occasionally you come across a showstopper like the above where
PowerShell script operates very differently to normal languages. I think the
example above could trip up a lot of people.

I wonder if there's a good reason for PowerShell parameter passing to work
in the way it does?

Just found this, which is related:-

http://www.vista64.net/forums/archiv...hp/t-7526.html

IMO:
It is because Powershell wasn't meant to replace C# or VB.Net. Its meant for
none developers to be able to achieve the same powerful results as a
developer could, while maintaining the simplicity of batch scripting. It is
probably good to remember that Powershell is also meant to be dynamic and
interactive. In an interactive environment the way Powershell works is more
intuitive.

"Andrew Webb" <AndrewWebb@discussions.microsoft.com> wrote in message
news:F26318EF-EADF-4B79-A266-25CFF8142482@microsoft.com...
>> your syntax would be right when calling a dotnet method, but for a
>> powershell function what you are doing is with
>>
>> > MyFunc2("hello",$true)
>>
>> is passing an object[] array with two items in it as the input.
>
> Thank you. That's the information I've been looking for all afternoon!
>
> After some testing:-
>
> # this works
> MyFunc2 "hello" $true
>
> # these don't work
> #MyFunc2 ("hello" $true)
> #MyFunc2 ("hello", $true)
> #MyFunc2 "hello", $true
>
> I think that what is confusing is that in some ways PowerShell is "very
> .NET
> like" and in other ways it isn't. I've been converting some boilerplate
> C#
> and VB.NET into PowerShell script, and for the most part it goes
> smoothly...
> but occasionally you come across a showstopper like the above where
> PowerShell script operates very differently to normal languages. I think
> the
> example above could trip up a lot of people.
>
> I wonder if there's a good reason for PowerShell parameter passing to work
> in the way it does?
>

Andrew Webb wrote:
> I wonder if there's a good reason for PowerShell parameter passing to work
> in the way it does?
The powershell team decided that script functions would be a way to
implement commands. And when you type a command, you don't put
parentheses around the arguments or quotes around the string arguments:

get-childitem dir

not get-childitem("dir")


The only time you put parentheses around arguments is when calling .NET
functions, since those are obviously functions and not powershell commands.

So script functions let you write powershell commands, and are invoked
like powershell commands.

> The powershell team decided that script functions would be a way to
> implement commands. And when you type a command, you don't put
> parentheses around the arguments or quotes around the string arguments:
>
> get-childitem dir
>
> not get-childitem("dir")
>
>
> The only time you put parentheses around arguments is when calling .NET
> functions, since those are obviously functions and not powershell commands.
>
> So script functions let you write powershell commands, and are invoked
> like powershell commands.

Thanks. In this case what would be good IMO is if the calls to MyFunc and
MyFunc1 (see my original script) *didn't* work with parens. Then things
would be consistent. Not complaining - just an observation.

> It is because Powershell wasn't meant to replace C# or VB.Net. Its meant for
> none developers to be able to achieve the same powerful results as a
> developer could, while maintaining the simplicity of batch scripting. It is
> probably good to remember that Powershell is also meant to be dynamic and
> interactive. In an interactive environment the way Powershell works is more
> intuitive.

Thanks. For sure PowerShell isn't and shouldn't be a replacement for C# and
the like. I'm heavily pushing the take-up of PowerShell at my day job, and I
know that non-devs will call on the likes of me to help with their scripting
(happens with their current VBScripting etc.) so it's good I'm going through
the PS learning curve right now. I think the curve is deceptively steep, but
I am enjoying it. For sure PowerShell rocks!

Andrew Webb wrote:
> Thanks. In this case what would be good IMO is if the calls to MyFunc and
> MyFunc1 (see my original script) *didn't* work with parens. Then things
> would be consistent. Not complaining - just an observation.

Ahh, well this is a case it looking like one thing and being something
else. It's actually executing a sub-command and passing the result as an
argument. These are the same:

PS> command(2+2) # looks like a function??
PS> command (2+2) # less obviously a function
PS> get-childitem ($base + "subdir") # a more realistic example

The reason MyFunc and MyFunc1 "worked" is that "hello" is the same as
("hello") which is the same as (((("hello")))). If you think of it in
terms of putting parentheses around parts of an expression...

However, if they required some space between the command name and the
arguments, I'd consider it a good idea. That's the natural way of
writing a command on the command line, and if enforced, it would prevent
most people from accidentally calling script functions with parentheses
when they weren't intended.

But then you'd have other people complaining about the "significant
whitespace". :-)

Your functions should be called like command line utilities, *not* like
routines.

Calling a function with the pattern of

<functionname><paren>value</paren> (e.g., MyFunc("hello") )

should not be encouraged or used in general and represents a
misunderstanding of the way the shell works - always keep in mind that these
are arguments to command line utilities, not the programmers view of
arguments to methods or routines.

The first example works by happy circumstance (e.g., ("hello") is an
expression that returns the string "hello"). The last example fails for
the same reason. ("hello",$true") is an expression that returns an array of
which the first element is a string and the second element is a boolean.
The MyFunc2 function takes two arguments, the first being a string, the
second being a boolean. We handle the parameter binding in the string
parameter case because we can convert an array to a string. But, since the
second argument is a boolean, we provide $null as a value to that parameter
which causes the error that you see. (due to the fact that we don't
automatically cast $null to a boolean when in a parameter binding context)

The bottom line is that, as a rule, you should frown on using the functions
of the shell like a method, because it will lead to this seeming
inconsistency. Rather, you should provide arguments to functions in the
same way that you provide them to cmdlets and commands:

MyFunc2 argument1 argument2

which is directly equivalent to

Get-ItemProperty Path Name

This rule changes, of course, when you use the .NET objects directly, but
then you're calling real methods on objects rather than commands that are
implemented via function declaration. We did consider that we should make
method calls more like cmdlet invocation to improve consistency, but at the
end of the day, we reckoned that the developer types that would actually be
using the object/method features would understand the differences between
the two (method invocation and command arguments).

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

"Andrew Webb" <AndrewWebb@discussions.microsoft.com> wrote in message
news:4B9B576E-5CC9-4387-9638-0DC4A1B8BA44@microsoft.com...
> function MyFunc ([string]$text)
> {
> write-host $text
> }
>
> function MyFunc1 ([bool]$flag)
> {
> write-host $flag
> }
>
> function MyFunc2 ([string]$text,[bool]$flag)
> {
> write-host $text
> write-host $flag
> }
>
> MyFunc("hello")
> MyFunc1($true)
> MyFunc2("hello",$true)
>
>
> # The call to MyFunc2 generates error: Cannot convert value "" to type
> "System.Boolean". What am I doing wrong?
>
>