Usages of defaultParameters and parameterNames
apaku at gmx.de
Mon Feb 25 22:14:23 UTC 2008
On 24.02.08 23:24:20, David Nolden wrote:
> On Sunday 24 February 2008 14:25:18 Andreas Pakulat wrote:
> > On 24.02.08 13:58:42, Andreas Pakulat wrote:
> > > Hi,
> > >
> > > how are the above functions from AbstractFunctionDeclaration used in
> > > C++? According to the docs defaultParameters may be a problem for
> > > python, because a python function can have:
> > >
> > > def foo(bar=1,*foo,**baz)
> > >
> > > i.e. the last defaultParameter is not necessarily the last paramter. I'm
> > > thinking we might need to introduce a proper list of structures there,
> > > something very simple with just a name an optional a value.
> The problem is memory-usage, because that list would be created for every
> single function out there. What about just filling up the not given
> default-parameters with QString()?
Well, the question really is: What happens if there's a parameter
_after_ the last one with a default value. As far as I can see there's
basically no connection between the parameter name list and the default
value list. Thus my impression is that it doesn't have any meaning,
there's no way with that API to find the parameter name for a given
default value (and knowing its position from the end) or vice versa. So
I guess I don't even need an empty QString, I just pass the default
values I have and act as if the list and dict parameters don't exist.
> > Actually, I've got even worse problems. I can't really fill these except
> > for the simplest case of a parameter name. But in python I can also have
> > a list of parameter names (like def foo( (bar,baz,foo) ) as 1 argument.
> > Where of course each name is a separate variable inside the function,
> > but you can only call that function either as
> > foo() or foo([1,5,2]) (or anything else in the list). And I can access
> > the 3 elements with the names.
> > So I'm thinking about simply not filling these, if they're not that
> > important.
> I think currently the parameter-names are used while completion to show the
> name. However it should also be possible to extract them from the
> function-context, so maybe we could even remove that whole thing.
Ok, I guess I could just fill in a "(<p1>,<p2>,...)" as parameter name
> > Also something similar exists for the default values, that can be any
> > arbitrary expression.
> In C++ the default-values are evaluated as expressions on demand, and are also
> shown in the argument-hints, so they are quite useful. Probably in python
> they should be useful too.
So c++ support fetches the "string" from the defaultValues list and
evaluates the expression in that string on demand, by parsing it as an
BTW: This is broken right now. For
void bar( int i, int j = 0, char* foo = "test" );
The argument hint gives me:
void bar( int i = 0, int j = "test" , char* foo = 0 );
> However, are single default-parameters even possible for that "(bar, baz,
> foo)" thing? Doesn't python expect the given parameter to be a 3-tuple, so a
> default-parameter should more look like def foo( (bar,baz,foo) = [0,1,2] ).
Yes, if that expression evaluates to a 3-tuple or 3-element-list, i.e.
>>> def foo((d,e,f)=a):
works just fine.
> So the problems would be those *foo and **baz things, but I would also count
> those as single parameters, so it should be possible to fill the
Yeah, the parameter names are not that much of a problem as I said above
I can just put (....) as 1 parameter name.
Your reasoning is excellent -- it's only your basic assumptions that are wrong.
More information about the KDevelop-devel