{"id":178,"date":"2019-07-08T09:48:46","date_gmt":"2019-07-08T15:48:46","guid":{"rendered":"https:\/\/www.great-white-software.com\/blog\/?p=178"},"modified":"2019-07-04T09:49:13","modified_gmt":"2019-07-04T15:49:13","slug":"named-parameters","status":"publish","type":"post","link":"https:\/\/www.great-white-software.com\/blog\/2019\/07\/08\/named-parameters\/","title":{"rendered":"Named parameters"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Currently when you call a method in Xojo the parameters are matched up starting from the first to the last from left to right. They are matched up based on their position in the argument list.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">One thing some other languages support is &#8220;named parameters&#8221;.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What this allows is a certain degree of flexibility that doesn&#8217;t exist with positional parameters like Xojo uses.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For instance in Xojo if you have a method, Foo, with parameters as follows<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Sub Foo(a as integer, b as string, c as Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">you can call it only using the correct types of parameters in the correct order like<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Foo(123, \"345\", new Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">There are ways, with optional parameters, to modify this normal operations. If that method was defined as<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Sub Foo(a as integer = -1, b as string = \"\", c as Date = nil)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">You could call this like<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Foo()\nFoo(123)\nFoo(123, \"345\")\nFoo(123, \"345\", new Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">All the parameters are optional and any that are not supplied a default value as shown in the declaration. But everything is still positional. And there are things you cannot do like skip one parameter. None of these will compile.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\nFoo(, ,New Date)\nFoo( , \"345\" ,New Date)\nFoo(123, ,New Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">So how would named parameters help ? Named parameters can let you say, explicitly, &#8220;this value is for this parameter&#8221; rather than just matching up by position. For instance out call to Foo might look like <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Foo()\nFoo( a:123)\nFoo( a:123, b:\"345\")\nFoo( a:123, b:\"345\", c:new Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">And you might also be able to do something like<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Foo( b:\"345\", a:123 )\nFoo( a:123, c:new Date, b:\"345\")<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">And not have to worry about the order. And this might let you do something like<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Foo(c:New Date)\nFoo( b:\"345\" , c:New Date)\nFoo(a:123, c:New Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">which skips certain parameters in a manner that you cannot do today.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Certainly this would not be a trivial change to Xojo to support positional and\/or named parameters. But there are languages that do this.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In the mean time its possible to manually create your own support for &#8220;named parameters&#8221;. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If we create Foo with two signatures like <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Sub Foo(a as integer = -1, b as string = \"\", c as Date = nil)\nEnd Sub\nSub Foo(paramarray values as Pair)\nEnd Sub<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then Foo could be called as<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Foo(123, \"345\")\nFoo(123, \"345\", New Date)\nFoo( \"c\":New Date)\nFoo( \"b\":\"345\" , \"c\":New Date)\nFoo( \"a\":123, \"c\":New Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">NOTE that the &#8220;names&#8221; of the parameters have to be a literal type &#8211; in this case a string. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In this  set up though we cant use no parameters. So let&#8217;s alter the set up to have at least one parameter otherwise the compiler will have an ambiguous overload in the case there are no parameters. It couldn&#8217;t distinguish between the call to Foo where it should use all default parameters and an empty paramarray. So now our declarations look like<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Sub Foo(a as integer = -1, b as string = \"\", c as Date = nil)\nEnd Sub\nSub Foo(value as pair, paramarray values as Pair)\nEnd Sub<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">And we&#8217;ll be able to call this like<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/\/ these are positional\nFoo\nFoo(123)\nFoo(123, \"345\")\nFoo(123, \"345\", New Date)\n\n\/\/ the use \"named\" parameters\nFoo( \"c\":New Date)\nFoo( \"b\":\"345\" , \"c\":New Date)\nFoo( \"a\":123, \"c\":New Date)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">So we&#8217;re on our way to being able to use either positional parameters OR named parameters. Now how do we make use of the overload that supports named parameters to call the one that supports positional parameters ?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In this method we need to<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>make sure we declare one local variable of the same type for each positional parameter<\/li><li>make sure we set these local variables default value to the same default values as the version that uses positional parameters<\/li><li>process the FIRST pair and all subsequent pairs in the same fashion and assign values to the local variables<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Following all those admonitions the code in the version of foo using named parameters looks like <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Dim a As Integer = -1\nDim b As String \nDim c As Date\n\nSelect Case value.Left\nCase \"a\"\n  a = value.Right.IntegerValue\nCase \"b\"\n  b = value.Right.StringValue\nCase \"c\"\n  c = value.Right\nEnd Select\n\nFor i As Integer = 0 To values.ubound\n  \n  Select Case values(i).Left\n  Case \"a\"\n    a =  values(i).Right.IntegerValue\n  Case \"b\"\n    b =  values(i).Right.StringValue\n  Case \"c\"\n    c =  values(i).Right\n  End Select\n  \nNext\n\nfoo(a, b, c)\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">There are caveats to this technique though. Positional parameters will be checked by the compiler for type, the &#8220;named parameter&#8221; version will only be checked that the passed items ARE pairs. The names and values contained by those pairs are variants and so can be anything. And you can pass the same named parameter multiple times since the compiler is unaware of named parameters. And you can&#8217;t use &#8220;byref&#8221; parameters with the named parameter version &#8211; you COULD use reference types though.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I&#8217;d love to see Xojo support named and positional parameters using a syntax that looks like &#8220;pairs&#8221; as first presented.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In the mean time this is what we have.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Currently when you call a method in Xojo the parameters are matched up starting from the first to the last from left to right. They are matched up based on their position in the argument list. One thing some other languages support is &#8220;named parameters&#8221;. What this allows is a certain degree of flexibility that &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/www.great-white-software.com\/blog\/2019\/07\/08\/named-parameters\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Named parameters&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[1],"tags":[6,3],"class_list":["post-178","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-tips","tag-xojo"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts\/178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/comments?post=178"}],"version-history":[{"count":2,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts\/178\/revisions"}],"predecessor-version":[{"id":180,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts\/178\/revisions\/180"}],"wp:attachment":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/media?parent=178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/categories?post=178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/tags?post=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}