-
Notifications
You must be signed in to change notification settings - Fork 268
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
Add before and after capability to specify blocks #380
Comments
👍 |
Here is the specific use case where I feel this may be nice. I'd love to hear your opinions as to why this is or is not a good use case. I have an assembly and my view of the assembly is that it plays a role in setting up the app. If built to use/rely upon Typhoon, the app cannot run without it. There are some things that you might traditionally put in the AppDelegate, primarily because there is no other good place for them, but for really no other reason. For example, I want to configure the shared NSURLCache. It doesn't need to be injected anywhere in the app. One of the libraries I'm using (AFNetworking) uses the shared cache. It simply needs to be configured. I would love to use the enhancement I've requested to configure the shared NSURLCache there after injection of AppDelegate. I could make an argument that the configuration of the shared NSURLCache fits nicely within Typhoon, but would love to hear your feedback. Technically speaking, the shared NSURLCache is not a dependency of any class I need to inject. As Typhoon is a dependency injector, I could see that your opinion may be that if it's not a dependency of something, it shouldn't be in an Assembly. Just looking for a bit more info on your opinion and why #258 as closed/declined. |
Hi @JeffBNimble . . I see it the same way you do. I think #258 was closed just because of other priorities, and we don't like to have too many issues opened at once. I also raised this idea way back, and folks at the time suggested it wasn't a good idea, and to instead just use the before/after injections methods. . . I can't remember the exact reasons, but it was a quick discussion, not a detailed analysis of the pros and cons, and I figured it would get raised again sooner or later. The only drawback I can see is that we forfeit some simplicity, but Typhoon already provides a few ways to do this kind of thing, and this flexibility appeals to users. Would you be interested in implementing the feature? |
Another related issue: #265 |
Closing this as stale. We'll have something like this in pilgrim.ph (Swift successor to Typhoon). |
As a Typhoon user,
I would like to specify a block of code (closure) for either/both before and after injections,
So that I can specify a block that gets executed and passed the instance created by Typhoon.
It would be nice to be able to specify blocks in addition to selectors for performBefore: and performAfter.
For example:
Where the block is passed the instance created as an argument. Of course, implementers would have to cast the instance to the type.
The text was updated successfully, but these errors were encountered: