Named arguments can be used with dynamic libraries

[GoogleCodeExporter]

Named arguments (issue 215) is a powerful feature that currently is only 
supported with user keywords and libraries implemented with Python that use the 
static library API. It would be great if also dynamic libraries were supported. 
It would be extra cool if also remote libraries, that use the dynamic library 
API via Remote library, were supported too.

Original issue reported on code.google.com by pekka.klarck on 25 Apr 2012 at 8:05

[GoogleCodeExporter]

The support for named arguments should be implemented so that the dynamic 
library API does not change in backwards incompatible manner. It would be even 
better if existing libraries could get the support automatically without 
changing how they work. I believe both of these goals can be achieved if we 
implement this support so that we use the information got from 
get_keyword_arguments method. How to do that in practice is explained with the 
example below:

1) Assume a dynamic library implements keyword X and get_keyword_arguments 
returns argument specification ['a1=foo', 'a2=boo'] for that keyword. This 
argspec means that the keyword has two arguments ('a1' and 'a2') and they both 
have default values ('foo' and 'boo', respectively).

2) User uses the keyword like `| X | a2=zap |` meaning to specify only the 
value for the second argument and using the default value with the first one.

3) Framework notices that named arguments are used. It calls run_keyword method 
so that it adds the default value for the first argument itself: 
`run_keyword('X', ['foo', 'zap'])`.

The above solution ought to work pretty well and shouldn't cause too much 
backwards incompatibility problems. This does, however, change the syntax 
slightly and thus can only be implemented in a major release.

Original comment by pekka.klarck on 25 Apr 2012 at 8:14

• Added labels: bwic

[GoogleCodeExporter]

This topic has been also discussed on rf-users:
http://groups.google.com/group/robotframework-users/browse_thread/thread/6b0d3ab
929571982

Original comment by pekka.klarck on 25 Apr 2012 at 8:14

[GoogleCodeExporter]

Awesome! Really looking forward to this.
I've been working around this successfully by specifying : instead of = for 
"named arguments," and modifying the remote server to parse it and figure it 
out, whether or not it's named. Having it built-in will be much better, namely 
because RIDE will be able to prevalidate the arguments that way.

Original comment by SamerA...@gmail.com on 26 Apr 2012 at 2:08

[GoogleCodeExporter]

Original comment by kontu...@gmail.com on 28 Mar 2013 at 8:00

• Changed state: Started

[GoogleCodeExporter]

This issue was updated by revision ceb6f8496cdd.

started implementation with tests. need cleanup

Original comment by kontu...@gmail.com on 28 Mar 2013 at 3:04

[GoogleCodeExporter]

This issue was updated by revision 04418a4a00d2.

Original comment by kontu...@gmail.com on 28 Mar 2013 at 3:06

[GoogleCodeExporter]

Also missing some test cases and documentation.

Right now, the implementation follows the way Robot does things, meaning:

# dynamic library in Python

def foo(a, b):
    print a, b

foo(1, b=2)
# => "1 2"

# in Robot, right now

Foo    1    b=2
# => "1 b=2"

This needs to be discussed if this is okay.

Original comment by tatu.ka...@eficode.com on 28 Mar 2013 at 3:14

[GoogleCodeExporter]

This issue was updated by revision 511f5b48e386.

Original comment by tatu.ka...@eficode.com on 5 Apr 2013 at 12:24

• Changed state: Review

[GoogleCodeExporter]

The implementation was fixed from what is describred in the comment above to
work just as everything else in Robot. Meaning:

# dynamic library in Python

def foo(a,b):
    print a,b

foo(1, b=2)
# => "1 2"

#in Robot

Foo    1     b=2
# => "1 2"

Original comment by tatu.ka...@eficode.com on 5 Apr 2013 at 12:27

[GoogleCodeExporter]

Is the implementation going to work with remote libraries? Particularly 
non-Python remote libraries (Java, C#, Perl, etc.), in which case, is the 
protocol for using named arguments going to be similar to what Pekka suggested 
in the referenced user group discussion?

The implementation wouldn't be complete w/o remote library support and update 
of the documentation on how this would work with remote libraries, in my 
opinion anyways.

Original comment by manga...@gmail.com on 5 Apr 2013 at 6:19

[GoogleCodeExporter]

@mangaroo: The plan is to support also remote libs.

Original comment by pekka.klarck on 9 Apr 2013 at 2:23

[GoogleCodeExporter]

This issue was updated by revision 4c8cff4df2e9.

Original comment by tatu.ka...@eficode.com on 11 Apr 2013 at 10:19

[GoogleCodeExporter]

Original comment by jussi.ao...@gmail.com on 10 May 2013 at 12:24

• Changed state: Done

[GoogleCodeExporter]

Documentation is covered by issue 1430

Original comment by jussi.ao...@gmail.com on 10 May 2013 at 12:26

[GoogleCodeExporter]

Populating all the default arguments automatically leads to some problems. This 
causes for example the JavaLibCore method overloading to stop working: the 
overloaded methods are not called anymore. The framework will simply populate 
all the possible arguments (even with empty values!)

It would be more backwards compatible if the framework would not populate the 
default values automatically unless necessary.

For example with this argument signature:
a, b=2, c=3

now giving only argument 1 leads to framework calling the method with arguments 
1, 2, 3

I would expect this behaviour:
1  -> call: 1
1, b=4 -> call: 1, 4
1, c=5 -> call: 1, 2, 5

Original comment by jussi.ao...@gmail.com on 14 May 2013 at 7:58

• Changed state: Started

[GoogleCodeExporter]

Implemented in ra0bac0589fd9 and cleaned up tests in r5645bd884388

Original comment by jussi.ao...@gmail.com on 19 May 2013 at 5:33

• Changed state: Review

[GoogleCodeExporter]

Cleanup after review rb3b3ad8bab49

Original comment by jussi.ao...@gmail.com on 20 May 2013 at 8:50

• Changed state: Done

[GoogleCodeExporter]

Original comment by anssi.sy...@eficode.com on 31 May 2013 at 12:37

• Changed title: Named arguments can be used with dynamic libraries

[GoogleCodeExporter]

Original comment by tatu.ka...@eficode.com on 31 May 2013 at 1:56

• Removed labels: bwic