Skip to content
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

There's no way to reference mixin method #43

Closed
inossidabile opened this issue May 18, 2012 · 5 comments
Closed

There's no way to reference mixin method #43

inossidabile opened this issue May 18, 2012 · 5 comments

Comments

@inossidabile
Copy link
Member

Current implementation of referencer allows the . and # delimiters according to the class and instance methods. On the other side everything we receive from mixin is marked as a mixin method.

Inside referencer we do search through mixins. However delimeter-type filters will always reject the mixins methods. So there's totally no way to reference to mixin method. And that's just wrong.

@inossidabile
Copy link
Member Author

I have a ready patch that allows addressing mixins methods like class methods (which I believe is quite natural). @netzpirat I need your opinion here before I modify the master :)

@inossidabile
Copy link
Member Author

I've noticed that we use '?' sign to mark mixin-typed methods. This could be another solution for the referencer. Foo.Bar?method does not look very natural though 😳

@netzpirat
Copy link
Contributor

Normal classes can have class and an instance method with the same name, thus we need the method prefix to distinguish them. However this is not the case for a mixin, since all methods are declared as instance methods. I have chosen the question mark for displaying the method signature to point out that we do not know whether the method will be used as class or instance method. I think we should allow all prefixes #, . and even ? to reference a mixin method, so the document author can add this semantics to the docs with his implementation knowledge.

@inossidabile
Copy link
Member Author

I agree that we should allow both types of prefixes. However I vote against ?. I think this can be misused. You always know which type of extension you expect. There's no reason to define ? manually as well. If you don't mind I'll patch it with . or # support.

@netzpirat
Copy link
Contributor

Thats perfectly fine. Thanks a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants