Fix issue 3309 parameter names trait #951

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
6 participants
@jmaschme

Added a new traits call to get the parameter names of a function

Fix issue 3309
Added a new traits call to get the parameter names of a function
@jmaschme

This comment has been minimized.

Show comment
Hide comment
@JakobOvrum

This comment has been minimized.

Show comment
Hide comment
@JakobOvrum

JakobOvrum May 14, 2012

Member

All traits returning lists were changed to return expression tuples instead of arrays (e.g. allMembers and friends).

I think this should do the same for consistency.

Member

JakobOvrum commented May 14, 2012

All traits returning lists were changed to return expression tuples instead of arrays (e.g. allMembers and friends).

I think this should do the same for consistency.

src/traits.c
+ else if (ident == Id::parameterNames)
+ {
+ FuncDeclaration *f;
+ Dsymbol *s = getDsymbol((Object *)args->data[0]);

This comment has been minimized.

@yebblies

yebblies May 15, 2012

Member

New code should not be using the data member of arrays. Use (*args)[0] instead, it's typed correctly.

@yebblies

yebblies May 15, 2012

Member

New code should not be using the data member of arrays. Use (*args)[0] instead, it's typed correctly.

@mrmonday

This comment has been minimized.

Show comment
Hide comment
@mrmonday

mrmonday May 16, 2012

Contributor

It would be cool if this returned a tuple of symbols rather than strings - the strings can then be acquired from the symbols if needed.

Contributor

mrmonday commented May 16, 2012

It would be cool if this returned a tuple of symbols rather than strings - the strings can then be acquired from the symbols if needed.

@mrmonday

This comment has been minimized.

Show comment
Hide comment
@mrmonday

mrmonday May 16, 2012

Contributor

It would also be useful if default arguments could be acquired from this too.

Contributor

mrmonday commented May 16, 2012

It would also be useful if default arguments could be acquired from this too.

@jmaschme

This comment has been minimized.

Show comment
Hide comment
@jmaschme

jmaschme May 16, 2012

Interesting ideas. I went with string names only because that was the biggest piece missing from the introspection capabilities. And of course, there was already a bug report on it with a patch that I used as the starting point.

Perhaps we should be considering a more generalized getParameters trait? We can already get argument types from std.traits. If you add parameterNames, the only thing missing would be default arguments. Is that enough of a reason for a more generalized trait?

Interesting ideas. I went with string names only because that was the biggest piece missing from the introspection capabilities. And of course, there was already a bug report on it with a patch that I used as the starting point.

Perhaps we should be considering a more generalized getParameters trait? We can already get argument types from std.traits. If you add parameterNames, the only thing missing would be default arguments. Is that enough of a reason for a more generalized trait?

@JakobOvrum

This comment has been minimized.

Show comment
Hide comment
@JakobOvrum

JakobOvrum May 17, 2012

Member

It would be cool if this returned a tuple of symbols rather than strings - the strings can then be acquired from the symbols if needed.

Those symbols only exist inside the function itself. How would it work in general? I don't see how it could.

Member

JakobOvrum commented May 17, 2012

It would be cool if this returned a tuple of symbols rather than strings - the strings can then be acquired from the symbols if needed.

Those symbols only exist inside the function itself. How would it work in general? I don't see how it could.

@mrmonday

This comment has been minimized.

Show comment
Hide comment
@mrmonday

mrmonday May 17, 2012

Contributor

@JakobOvrum Good point. I'm not sure how best to handle that, perhaps as @jmaschme suggested we could have a getParameters trait that only worked within a function/method?

Contributor

mrmonday commented May 17, 2012

@JakobOvrum Good point. I'm not sure how best to handle that, perhaps as @jmaschme suggested we could have a getParameters trait that only worked within a function/method?

@JakobOvrum

This comment has been minimized.

Show comment
Hide comment
@JakobOvrum

JakobOvrum May 17, 2012

Member

@mrmonday, aye, I think that would be great, and I know of at least two people who have asked about exactly this kind of thing before on IRC (using the parameters to the current function as an expression tuple). Retrieving the symbol for the current function is also a frequently requested feature (simplifying interfaces for a lot of mixin-style code).

Either way, I want to thank @jmaschme for taking on these important issues. Your effort is greatly appreciated!

Member

JakobOvrum commented May 17, 2012

@mrmonday, aye, I think that would be great, and I know of at least two people who have asked about exactly this kind of thing before on IRC (using the parameters to the current function as an expression tuple). Retrieving the symbol for the current function is also a frequently requested feature (simplifying interfaces for a lot of mixin-style code).

Either way, I want to thank @jmaschme for taking on these important issues. Your effort is greatly appreciated!

@TurkeyMan

This comment has been minimized.

Show comment
Hide comment
@TurkeyMan

TurkeyMan Jun 19, 2012

Contributor

@mrmonday Only working within a function/method may not be sufficient.
I believe this would be used extensively to copy parameter lists to generated functions...

void someOtherFunction(int x, float y = 10.0);
void newFunc(bool test, ParameterListOf!someOtherFunction);

In this case, newFunc should be: newFunc(bool test, int x, float y = 10.0), ie, the copied parameters are NOT a tuple argument, they are 1st class parameters, retaining their names and default args.
I need this for generated user facing API's. This allows auto-complete, intellisense, documentation, pop-up helper tooltips, etc to all work as expected.

Note: Syntax in my example is for illustration only. I don't care at all how it's implemented, assuming the result is the same...

@JakobOvrum, Yeah, I've often needed typeof(this_function), or something to that effect.

Contributor

TurkeyMan commented Jun 19, 2012

@mrmonday Only working within a function/method may not be sufficient.
I believe this would be used extensively to copy parameter lists to generated functions...

void someOtherFunction(int x, float y = 10.0);
void newFunc(bool test, ParameterListOf!someOtherFunction);

In this case, newFunc should be: newFunc(bool test, int x, float y = 10.0), ie, the copied parameters are NOT a tuple argument, they are 1st class parameters, retaining their names and default args.
I need this for generated user facing API's. This allows auto-complete, intellisense, documentation, pop-up helper tooltips, etc to all work as expected.

Note: Syntax in my example is for illustration only. I don't care at all how it's implemented, assuming the result is the same...

@JakobOvrum, Yeah, I've often needed typeof(this_function), or something to that effect.

@WalterBright

This comment has been minimized.

Show comment
Hide comment
@WalterBright

WalterBright Jul 1, 2012

Member

Done as: 08811d7

Member

WalterBright commented Jul 1, 2012

Done as: 08811d7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment