Skip to content

MethodTag::getArguments #29

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
armetiz opened this issue Jan 13, 2014 · 6 comments
Closed

MethodTag::getArguments #29

armetiz opened this issue Jan 13, 2014 · 6 comments
Assignees

Comments

@armetiz
Copy link

armetiz commented Jan 13, 2014

This function return an array of array, there is no defined order of this structure.

I guess it could be useful to add a correct interpretation of this information : [[type] [parameter]<, ...>]

There is 3 informations :

  • name
  • type
  • default value
@cebe
Copy link
Contributor

cebe commented Jan 13, 2014

Could return instances of FunctionReflector\ArgumentReflector just like a normal method.

@johannesschobel
Copy link

It would be awesome if we could access the various information of a tag! Any implementation available?

@ashnazg
Copy link
Member

ashnazg commented Aug 23, 2018

It looks to me like nearly everything this library provides is string-based, rather than reflectors... @jaapio @mvriel , does that sound right to you? If so, then we probably don't want to bend things into the latter, unless we went whole hog and made everything return reflectors.

Thoughts, anyone?

@jaapio
Copy link
Member

jaapio commented Aug 23, 2018

The mentioned reflection classes are part of phpdocumentor/reflection. I can imagine that we could create a param like class to support typed arguments. But before going that way I want to have a good benchmark setup avaliable. So we can measure the impact of changes like this.

I'm sure that we will get the same request for callables. And other complex docblock tags. Main concern is the memory usage in applications like phpdocumentor.

@ashnazg
Copy link
Member

ashnazg commented Aug 23, 2018

Right, but Reflection depends on ReflectionDocBlock, not the other way around. If the whole paradigm in ReflectionDocBlock is "return strings for all the info you ask for", I'd say it should stay that way in this library. Maybe the Reflection library itself could be the level of providing higher level classes wrapped around these strings.

@jaapio
Copy link
Member

jaapio commented Sep 27, 2021

I started an effort to get this thing done #304

@jaapio jaapio self-assigned this Oct 28, 2022
@jaapio jaapio closed this as completed Dec 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants