Named Parameters

[Peter Haworth]

Thanks Hugh, that's the idea I had in mind.

However, I'm beginning to see the limitations of this approach.  Unless I'm
missing something, it can only work if the right operand of the pair is a
literal value.  In other words, I could do something like "ChartSize=tVar",
where tVar is a variable in the handler that issues the call.  Similar
problem if I wanted to pass the id of control as the right operand.

So while I can make use of this technique when I want to pass literal
values, it seems that it the engine would have to recognise this syntax and
resolve any non-literal values involved before invoking the called
procedure.

I also learned something new - that there's a limit to the amount of data
you can pass in to handlers in parameters.  As far as I know I haven't run
into that but sounds like it's something that should be checked if there's
any danger that it could happen in any specific handler.


Pete
lcSQL Software <http://www.lcsql.com>



On Sat, May 5, 2012 at 1:11 AM, FlexibleLearning <admin at flexiblelearning.com
> wrote:

> ChartMaker uses the 'keyValue pairs' syntax (in the form "Key=Value"), of
> which any, some or all can be passed as parameters like this...
>
> get CMBarChart("ChartSize=500,300","Values=[list of
> values]","Categories=[list of categories]")
>
>
> The app first applies all the defaults in an internal array. It then parses
> any specified keyValue parameters to update the array that is then used to
> create the chart. The keyValues are finally stored in the chart for later
> use. Once the app's initial parsing scheme is written is it relatively
> straightforward to modify it with new keyValue pairs.
>
> The advantage of this method is that the order of the parameters is
> irrelevant and their contents can be optionally passed as variables for
> coding simplicity...
>
> get CMBarChart(tChartSize,tValues,tCategories)
>
>
> The main downside of passing parameters is the engine's limits on total
> parameter string length. If too much data is passed, the engine simply
> truncates the data to the maximum length it can handle.
>
> If the amount of data does exceed the engine's parameter-passing limit,
> then
> the data elements have to be iteratively set directly (e.g. set the uValues
> of group "Chart1" to [a very large dataset]). I personally find this a more
> cumbersome syntax than the keyValue syntax but it does mean there are
> limits. For ChartMaker, the limits are about 15,000 data points (depending
> on overall string length, of course).
>
> ChartMaker is available from www.FlexibleLearning.com/chartmaker
>
>
> Hugh Senior
> FLCo
>
>
>
> Peter Haworth wrote:
>
> I seem to recall somewhere in the dim distant past that some languages have
> a syntax where function and procedure calls can have named parameters
> rather than positional ones.
>
> function doIT p1,p2,p3,p4,p5,p6,p7,p8,p9,p10
> ..
> ..
> end doIT
>
> put doIT("abc",p3="xyz", p10="def") into tVar
>
> When functions have a large number of possible parameters but not all of
> them are required, this is a great way to avoid having to count commas in
> the calls to them.
>
> I don;t think LC has any such syntax built in but wondering if anyone has
> tried to implement something similar?
>
> Pete
> lcSQL Software <http://www.lcsql.com>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>