According to the documentation, PreparingEventArgs should have an Instance property, so you can supply an alternative instance instead of the default.
But as far as I can see, that property isn't there. Is it supposed to be there or not?
(I know I can swap the instance in the activating event, but I want to avoid creating an instance if I'll just have to throw it away anyway.)
What version of Autofac are you using?
In the latest source the Instance property is indeed removed. The alternative is to hook on to the Activating event and use the ReplaceInstance method on the ActivatingEventArgs.
Related
I am generating a class in ByteBuddy.
As part of one method implementation, I would like to set a (let's just say) public instance field in another object to the return value of a MethodCall invocation. (Keeping the example public means that access checks etc. are irrelevant.)
I thought I could use MethodCall#setsField(FieldDescription) to do this.
But from my prior question related to this I learned that MethodCall#setsField(FieldDescription) is intended to work only on fields of the instrumented type, and, looking at it now, I'm not entirely sure why or how I thought it was ever going to work.
So: is there a way for a ByteBuddy-generated method implementation to set an instance field of another object to the return value of a method invocation?
If it matters, the "instrumented method" (in ByteBuddy's terminology) accepts the object whose field I want to set as an argument. Naïvely I'd expect to be able to do something like:
MethodCall.invoke(someMethod).setsField(somePublicField).onArgument(2);
There may be problems here that I am not seeing but I was slightly surprised not to see this DSL option. (It may not exist for perfectly good reasons; I just don't know what they would be.)
This is not possible as of Byte Buddy 1.10.18, the mechanism was originally created to support getters/setters when defining beans, for example. That said, it would not be difficult to add; I think it would even be easiest to allow any custom byte code to be dispatched as a consumer of the method call.
I will look into how this can be done, but as a new feature, this will take some time before I find the empty space to do so. The change is tracked on GitHub.
I am using MethodCall.setsField() to try to set an instance field on another instance.
My generated class that is doing the field-setting, GC, is trying to set the value of an instance field in an instance of something it has created (CI). So the field's declaring type is CI; my field-setting code resides in GC (which is in the same package as CI but otherwise unrelated to it).
The ByteBuddy checks seem to indicate that although GC and CI are in the same package, GC must be assignable to CI in order to set this field! That greatly surprised me, but I am not a bytecode expert, and I might very well be overlooking something obvious. Could someone kindly explain why this check is necessary?
The method call sets the field implicitly on the this instance on which the method is invoked. For this to be possible, a non-static field must be declared by a super type of the type on which the method is invoked.
If you think this is too strict, please file an issue with an example of the code you are trying to generate, including the code to generate it which is currently failing. Maybe I am not thinking straight about this and if there's a restriction to be lifted, I would surely do it.
I'd like to have a project-wide variable which I can change during looking at that project. In other words, I'd like to get it affected whenever opening a file. Yes, I know .dir-locals.el exist in Emacs world. But I think it would be reset to the value set in .dir-locals.el whenever opening a file under that project.
Could I get some hints from you, please?
For this kind of thing you might want to use a function instead of a variable (directly). Specifically, use a getter and setter function.
All of your project code can invoke the getter function to get the value (which can be cached in a variable). And all of your code can invoke the setter function to change the value (which, again, can be cached in a variable).
These functions can be visible globally to your project. The cache variable would be accessed only by the getter and setter functions.
But as for code everywhere in your project being informed when the value gets updated and do what's appropriate with the new value whenever that happens, see #Phil's comment about the use of a variable - the same considerations apply.
You can have a hook in the setter function (or advise it), so that it does something additional (e.g. informs interested/subscribed code) whenever it updates the value.
For a variable you can do something similar using, as #Phils said in a comment, using add-variable-watcher.
For a user-option variable you can do something similar using :set and :get functions in the defcustom. (But those take effect only if changes are made using appropriate Customize functions or the Customize UI.)
You can eval in the dir-locals.el So, if you have a variable my-var that you want to be able to change with setq you could do something like
((nil . ((eval . (or (boundp 'my-var) (setq my-var 'default))))))
There are warnings about using eval in a dir-local though, since any code could be run there.
I'm working on Phratch (Scratch 2.0 in Smalltalk) and have modified the InputEventSensor>>processEvent method to store the last key pressed, in a similar manner to how the modifier keys are stored, so that they if <key> pressed blocks work.
So I now have a customised InputEventSensor class:
new instance variable keyPressed
modified method processEvent
new methods keyPressed and clearKeystate
The new methods are in a category *Phratch which is fine, so these get saved to the Phratch Monticello package. But what about processEvent, should that be moved to the *Phratch category? What about the instance variable?
There are several things going on :).
First, moving an existing method to your project's package is what we call an override. That is, when you load your package into the image, the existing method definition will be overriden by your definition. I wouldnt advice to make overrides only when extremely necessary. Actually, the best approach should be to create hooks, integrate them in Pharo's codebase, and then plug your project in the given hook :).
On extending classes with instance variables, I don't think Monticello handles that really. A possible solution is to add a pre-load action in a metacello configuration, adding the instance variable to the given class. That way, the inst var is installed before the methods.
Third and last, the actual good way to know if some key is still pressed, is to listen to the KeyDown and KeyUp events. A key is released when a KeyUp event is given. However, keyDown and keyUp events are not properly working on Pharo right now (in all platforms, the keycodes to identify the keys yield OS specific values, and there are some keys that are not well handled yet). But, I'm confident this will get better in the upcoming 3.0 version of Pharo.
Of course, you can contribute if you want to make any of this points better :).
If you request an unbound object from NInject, then the default behaviour is (if a suitable constructor is available) appears to be to create an instance of the appropriate object.
I'd like to disable this behaviour (I had a difficult to debug issue because something was auto-bound instead of picking up my custom binding in a module). This question hints that it is possible, but I'm unable to find the answer from the NInject wiki.
Remove the SelfBindingResolver from the kernel components after creation:
kernel.Components.RemoveAll<IMissingBindingResolver>();
kernel.Components.Add<IMissingBindingResolver, DefaultValueBindingResolver>();
The following is a better, more direct way of removing the SelfBindingResolver, without assuming that the DefaultValueBindingResolver is the only other IMissingBindingResolver component:
kernel.Components.Remove<IMissingBindingResolver, SelfBindingResolver>();
It's possible the Remove<T, TImplementation>() method was only added in a recent version of Ninject, but this works for me using Ninject 3.2.2.0.