-
Notifications
You must be signed in to change notification settings - Fork 151
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
format_with scope discussion #146
Comments
Another reason to rethink this feature is that in #56 we decided not to just overwrite exposures but think of them as method calls. So maybe we don't need just rewrite formatters dynamically too? |
The main caveat of the third variant is that formatter should be defined before its name is used in options passed to |
On the other hand, second variant makes think of formatters as helper methods and, you know, in Ruby access to methods is done using method table lookup when this method is needed. And the stackable behavior described above is also can also be implemented with the second approach. |
I don't see a problem with creating an anonymous class and inheriting it, although I don't see whether that improves anything. Try to make some code changes, I'd want to see the scope of changes for the user. |
I'm temporarily closing it. I tried to come up with an implementation and I don't like it. The main reason is that |
I want to do some refactoring in
Grape::Entity
that will help me face #56 and #140 issues easily.Another thing that stops me from doing it is a
format_with
feature. Don't ask me how it's exactly related to issues mentioned above. For now I just want to discuss some ways to improve theformat_with
feature.format_with
behavior is to storeproc
s informatters
table which is copied when entityA
is inherited by entityB
. So each entity has its own table of formatters. I'd like to call current implementation dynamically scoped.proc
s and the mechanism of copying is very similar to regular Ruby classes that support inheritance out of the box. We can substitute thisHash
table with an anonymousformatters
class and simply inherit it when the wholeEntity
is inherited. It will allow children formatters to refer overriden implementation (using Ruby'ssuper
) and even do mixins (withinclude
). Implementing this will be zero cost because all that inheritance stuff will be handled by Ruby. By the way, I also call this variant dynamically scoped.It's really breaking but it also adds flexibility as in the second variant and it's very similar to how
Grape
's DSL works (remember the stackable nature ofparams
). It will also allow us to define localformatters
, for example:So no inheritance tricks needed because now formatters are lexically scoped.
Internally it can also be implemented with anonymous class so it offers the same features as the second variant but the implementation will be more tricky.
What do you think? I'm in doubt but personally I like the third variant more.
The text was updated successfully, but these errors were encountered: